From silent_vendetta@REDACTED Sun May 1 00:25:38 2011 From: silent_vendetta@REDACTED (Chris Hicks) Date: Sat, 30 Apr 2011 15:25:38 -0700 Subject: [erlang-questions] Encrypting/Decrypting data In-Reply-To: References: Message-ID: This is a bit more of a general question than Erlang specific but I hope someone here can answer this, or simply point me to a place where it has already been answered. I'm writing a server in which I will be storing encrypted user data (unlike Sony). My problem is probably a product of zero experience with encryption combined with a lack of sleep, but I can't figure out how to do this securely. By that I mean I understand how to use crypto to encrypt/decrypt a piece of data but the Key and the Ivec have to be the same for both the encryption and decryption otherwise it doesn't work...so how do I make this happen without storing those two things "out in the open?" It seems like that can't be the optimal solution since anyone who could just grab those and decrypt the data. Am I missing something completely obvious? Chris Hicks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From silent_vendetta@REDACTED Sun May 1 00:31:30 2011 From: silent_vendetta@REDACTED (Chris Hicks) Date: Sat, 30 Apr 2011 15:31:30 -0700 Subject: [erlang-questions] Encrypting/Decrypting data In-Reply-To: References: , Message-ID: Of course right after hitting enter I thought of a possible solution...if I'm storing a record that looks something like: -record(data, {id, encrypted_data}). Would the solution be to create two functions (one for the Key and one for IVec) that take the plain/exposed id and create a binary of the proper size to be used in encrypting/decrypting? Obviously the functions would have to return the exact same output for any given input but, unless someone got their hands on the original code, that seems like it would be fairly secure. From: silent_vendetta@REDACTED To: erlang-questions@REDACTED Date: Sat, 30 Apr 2011 15:25:38 -0700 Subject: [erlang-questions] Encrypting/Decrypting data This is a bit more of a general question than Erlang specific but I hope someone here can answer this, or simply point me to a place where it has already been answered. I'm writing a server in which I will be storing encrypted user data (unlike Sony). My problem is probably a product of zero experience with encryption combined with a lack of sleep, but I can't figure out how to do this securely. By that I mean I understand how to use crypto to encrypt/decrypt a piece of data but the Key and the Ivec have to be the same for both the encryption and decryption otherwise it doesn't work...so how do I make this happen without storing those two things "out in the open?" It seems like that can't be the optimal solution since anyone who could just grab those and decrypt the data. Am I missing something completely obvious? Chris Hicks. _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From john@REDACTED Sun May 1 02:31:47 2011 From: john@REDACTED (John Kemp) Date: Sat, 30 Apr 2011 20:31:47 -0400 Subject: [erlang-questions] Encrypting/Decrypting data In-Reply-To: References: Message-ID: <5E0A3E92-4D97-432C-A882-E9F1CF45C61E@jkemp.net> Chris, On Apr 30, 2011, at 6:25 PM, Chris Hicks wrote: > This is a bit more of a general question than Erlang specific but I hope someone here can answer this, or simply point me to a place where it has already been answered. > > I'm writing a server in which I will be storing encrypted user data (unlike Sony). My problem is probably a product of zero experience with encryption combined with a lack of sleep, but I can't figure out how to do this securely. By that I mean I understand how to use crypto to encrypt/decrypt a piece of data but the Key and the Ivec have to be the same for both the encryption and decryption otherwise it doesn't work...so how do I make this happen without storing those two things "out in the open?" It seems like that can't be the optimal solution since anyone who could just grab those and decrypt the data. Am I missing something completely obvious? You have it correct. The solution to your problem is to do what things like 'ssh' or Apache 'httpd' do, and use a key stored in a file with user-restricted permissions, which requires a passphrase to read. As your server starts, it will ask the user who starts it for the passphrase and then read the key. Regards, - John Kemp > > Chris Hicks. > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From silent_vendetta@REDACTED Sun May 1 03:12:45 2011 From: silent_vendetta@REDACTED (Chris Hicks) Date: Sat, 30 Apr 2011 18:12:45 -0700 Subject: [erlang-questions] Encrypting/Decrypting data In-Reply-To: <5E0A3E92-4D97-432C-A882-E9F1CF45C61E@jkemp.net> References: , <5E0A3E92-4D97-432C-A882-E9F1CF45C61E@jkemp.net> Message-ID: That certainly makes sense, and is a lot simpler than anything I was coming up with in my head. Thank you. > Subject: Re: [erlang-questions] Encrypting/Decrypting data > From: john@REDACTED > Date: Sat, 30 Apr 2011 20:31:47 -0400 > CC: erlang-questions@REDACTED > To: silent_vendetta@REDACTED > > Chris, > > On Apr 30, 2011, at 6:25 PM, Chris Hicks wrote: > > > This is a bit more of a general question than Erlang specific but I hope someone here can answer this, or simply point me to a place where it has already been answered. > > > > I'm writing a server in which I will be storing encrypted user data (unlike Sony). My problem is probably a product of zero experience with encryption combined with a lack of sleep, but I can't figure out how to do this securely. By that I mean I understand how to use crypto to encrypt/decrypt a piece of data but the Key and the Ivec have to be the same for both the encryption and decryption otherwise it doesn't work...so how do I make this happen without storing those two things "out in the open?" It seems like that can't be the optimal solution since anyone who could just grab those and decrypt the data. Am I missing something completely obvious? > > You have it correct. The solution to your problem is to do what things like 'ssh' or Apache 'httpd' do, and use a key stored in a file with user-restricted permissions, which requires a passphrase to read. As your server starts, it will ask the user who starts it for the passphrase and then read the key. > > Regards, > > - John Kemp > > > > > Chris Hicks. > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.goertzen@REDACTED Sun May 1 04:16:45 2011 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Sat, 30 Apr 2011 21:16:45 -0500 Subject: [erlang-questions] snmp security name problems In-Reply-To: References: Message-ID: Never mind, I got it to work (hooray for wireshark and erlang tracing.) The problems were... 1. agent.conf is supposed to specify agent engine id, not manager engine id. 2. usm.conf is supposed to specify agent engine id and key generated from agent engine id. 3. OID needed a ",0" tacked onto the end. Dan. On Sat, Apr 30, 2011 at 3:21 PM, Daniel Goertzen wrote: > I am playing with erlang snmp managers, and am having trouble making my > first sync_get() command to a v3 agent work. I am getting > "unknownSecurityName" (see below), and I am stumped as to what might be > wrong. > > > I have What's Up Gold polling my v3 agent device, so I know the agent's > SNMP is working well. > > Any suggestions? > Thanks, > Dan. > > > > PS C:\cygwin\home\goertzen\bulk_config\srpc\ebin> C:\erlang\bin\erl.exe > -config C:\erlsnmp\sys.config > Eshell V5.8.2 (abort with ^G) > 1> crypto:start(). > ok > 2> snmp:start(). > ok > 3> snmpm:which_agents(). > ["myagent"] > 4> snmpm:which_usm_users(). > [{"hemi","abc123"}] > 5> snmpm:usm_user_info("hemi", "abc123",sec_name). > {ok,"abc123"} > 6> snmpm:sync_get(defaultuser, "myagent", [[1,3,6,1,2,1,1,1]]). > > =ERROR REPORT==== 30-Apr-2011::15:15:46 === > [ snmp : manager : snmpm_mpd : <0.61.0> ] > MPD: CONFIG ERROR: unknownSecurityName (message: {message,'version-3', > {v3_hdr,1261510722,484, > [7], > 3,undefined,undefined}, > > [48,65,4,32,56,48,58,48,48, > > 58,54,51,58,57,102,58,48, > > 51,58,48,48,58,52,48,58,53, > > 51,58,48,56,58,52,102,58, > 55,51,4,0,160,27,2,4,92, > > 103,199,2,2,1,0,2,1,0,48, > > 13,48,11,6,7,43,6,1,2,1,1, > 1,5,0]}) > > {error,{send_failed,1550305026,unknownSecurityName}} > 7> > > > usm.conf: > %% {EngineID, UserName, AuthP, AuthKey, PrivP, PrivKey}. > %% {EngineID, UserName, SecName, AuthP, AuthKey, PrivP, PrivKey}. > {"hemi", "abc123", "abc123", > usmHMACMD5AuthProtocol, > [122,254,237,74,242,75,191,73,255,25,189,190,102,250,156,25], % from > snmp:passwd2localized_key(md5,"abc123456","hemi") > usmDESPrivProtocol, > [122,254,237,74,242,75,191,73,255,25,189,190,102,250,156,25] % from > snmp:passwd2localized_key(md5,"abc123456","hemi") > }. > > agents.conf: > %% {UserId, > %% TargetName, Comm, Ip, Port, EngineID, Timeout, > %% MaxMessageSize, Version, SecModel, SecName, SecLevel} > %% > { defaultuser, "myagent", "", [192,168,1,50], 162, "engineid", infinity, > 484, v3, usm, "abc123", authPriv }. > > users.conf: > {defaultuser, snmpm_user_default, "dummy"}. > > manager.conf: > {port, 5000}. > {address, [192,168,1,104]}. > {engine_id, "hemi"}. > {max_message_size, 484}. > > sys.config: > [{snmp, > [ > {manager, > [ > {priority, normal}, > {versions, [v3]}, > {config, [{dir, "c:/erlsnmp/"}, {verbosity, silence}, {db_dir, > "c:/erlsnmp/data/"}, {repair, true}, {auto_save, 5000}]}, > {inform_request_behaviour, auto}, > {mibs, ["c:/erlang/lib/snmp-4.18/mibs/SNMPv2-MIB"]}, > {server, [{timeout,30000},{verbosity,silence}]}, > {note_store, [{timeout,30000},{verbosity,silence}]}, > {net_if, > [{module,snmpm_net_if},{verbosity,silence},{options,[{bind_to,false},{no_reuse,false}]}]} > ] > } > ] > } > ]. > > -- Daniel Goertzen ----------------- dang@REDACTED (work) daniel.goertzen@REDACTED (home) ----------------- 1 204 272 6149 (home/office) 1 204 470 8360 (mobile) ----------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jack@REDACTED Sun May 1 04:24:04 2011 From: jack@REDACTED (Jack Moffitt) Date: Sat, 30 Apr 2011 20:24:04 -0600 Subject: [erlang-questions] [ANN] Snack Words - Real-time, multi-player iOS game with Erlang backend In-Reply-To: References: Message-ID: > Did you wind up using a hosting service? ?If so, can you recommend it for hosted erlang? I host it on my Linode which runs (probably an old) Ubuntu. I've never had any problems. I've also used Erlang extensively on EC2, again using Ubuntu AMIs. I can recommend both systems, although EC2 is more expensive but also much more flexible. jack. From kenji.rikitake@REDACTED Sun May 1 06:47:19 2011 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Sun, 1 May 2011 13:47:19 +0900 Subject: [erlang-questions] ACM Erlang Workshop 2011 Call For Papers Message-ID: <20110501044719.GA86058@k2r.org> Note: ICFP 2011 will be held as planned in Tokyo, Japan, according to the Web pages of ICFP 2011 Local Information at: http://www.biglab.org/icfp11local/index.html (and so the ACM Erlang Workshop will be.) Kenji Rikitake CALL FOR PAPERS =============== Tenth ACM SIGPLAN Erlang Workshop --------------------------------- National Institute of Informatics (NII), Tokyo Japan Friday, September 23, 2011 A satellite event of the 16th ACM SIGPLAN International Conference on Functional Programming (ICFP) Erlang is a concurrent, distributed functional programming language aimed at systems with requirements on massive concurrency, soft real time response, fault tolerance, and high availability. It has been available as open source for over 10 years, creating a community that actively contributes to its already existing rich set of libraries and applications. Originally created for telecom applications, its usage has spread to other domains including e-commerce, banking, databases, and computer telephony and messaging. Erlang programs are today among the largest applications written in any functional programming language. These applications offer new opportunities to evaluate functional programming and functional programming methods on a very large scale and suggest new problems for the research community to solve. This workshop will bring together the open source, academic, and industrial programming communities of Erlang. It will enable participants to familiarize themselves with recent developments on new techniques and tools tailored to Erlang, novel applications, draw lessons from users' experiences and identify research problems and common areas relevant to the practice of Erlang and functional programming. We invite three sorts of submissions. 1. Technical papers describing language extensions, critical discussions of the status quo, formal semantics of language constructs, program analysis and transformation, virtual machine extensions and compilation techniques, implementations and interfaces of Erlang in/with other languages, and new tools (profilers, tracers, debuggers, testing frameworks, etc.). The maximum length for technical papers is restricted to 12 pages. 2. Practice and application papers describing uses of Erlang in the "real-world", Erlang libraries for specific tasks, experiences from using Erlang in specific application domains, reusable programming idioms and elegant new ways of using Erlang to approach or solve a particular problem. The maximum length for the practice and application papers is restricted to 6 pages. Papers in this category may be allocated less time for their talk and instead be given the opportunity for the poster presentations during the workshop. 3. Poster presentations describing topics related to the workshop goals. Each of them includes max 2 pages of the abstract and summary. Presentations in this category will be given an hour of shared simultaneous demonstration time. Workshop Chair -------------- * Kenji Rikitake, Kyoto University, Japan Program Chair ------------- * Erik Stenman, Klarna AB, Sweden Program Committee ----------------- (Note: the Workshop and Program Chairs are also committee members) * Clara Benac-Earle, Universidad Politecnica de Madrid (UPM), Spain * Johan Bevemyr, Tail-f Systems, Sweden * Scott Lystig Fritchie, Basho Technologies, USA * John Hughes, Quviq, Sweden * Takeru Inoue, NTT Network Innovation Laboratories, Japan * Kenneth Lundin, Ericsson, Sweden * Simon Thompson, University of Kent, UK * Robert Virding, Erlang Solutions, UK * Phil Wadler, University of Edinburgh, UK Important Dates --------------- * Submission deadline: Friday, June 3, 2011 * Author notification: Friday, June 17, 2011 * Final submission for the publisher: Friday, July 13, 2011 * Workshop date: Friday, September 23, 2011 Instructions to authors ----------------------- Papers must be submitted online via EasyChair (via the "Erlang2011" event). Submitted papers should be in portable document format (PDF), formatted using the ACM SIGPLAN style guidelines. Each submission must adhere to SIGPLAN's republication policy. Violation risks summary rejection of the offending submission. Accepted papers will be published by the ACM and will appear in the ACM Digital Library. Paper submissions will be considered for poster submission in the case that they are not accepted as full papers. Venue & Registration Details ---------------------------- * For registration, please see the ICFP 2011 web site at: Related Links ------------- * ICFP 2011 web site: * Past ACM SIGPLAN Erlang workshops: * Open Source Erlang: * EasyChair submission site: * Author Information for SIGPLAN Conferences: * Access map to NII: From qqshfox@REDACTED Sun May 1 16:32:34 2011 From: qqshfox@REDACTED (Hanfei Shen) Date: Sun, 1 May 2011 22:32:34 +0800 Subject: [erlang-questions] Erlang and MySQL: ODBC, Column type not supported Message-ID: Dear all, I'm a newbie programming in erlang. When I used ODBC to connect to a MySQL database through Connector/ODBC (MyODBC), I got some error when calling odbc:sql_query(Conn, "SELECT * FROM action"): {error,"Column type not supported"} Then I call odbc:describe_table(Conn, "action"), it returned: {ok,[{"id",sql_integer}, ???? {"code",'ODBC_UNSUPPORTED_TYPE'}, ???? {"compliment_desc",'ODBC_UNSUPPORTED_TYPE'}, ???? {"status_desc",'ODBC_UNSUPPORTED_TYPE'}, ???? {"parameter",'ODBC_UNSUPPORTED_TYPE'}, ???? {"cause",'ODBC_UNSUPPORTED_TYPE'}, ???? {"disabled",sql_tinyint}]} And desc the table in mysql client: mysql> desc action; +-----------------+--------------+------+-----+---------+----------------+ | Field?????????? | Type???????? | Null | Key | Default | Extra????????? | +-----------------+--------------+------+-----+---------+----------------+ | id????????????? | int(11)????? | NO?? | PRI | NULL??? | auto_increment | | code??????????? | varchar(255) | NO?? |???? | NULL??? |??????????????? | | compliment_desc | varchar(255) | NO?? |???? |???????? |??????????????? | | status_desc???? | varchar(255) | NO?? |???? |???????? |??????????????? | | parameter?????? | varchar(255) | NO?? |???? |???????? |??????????????? | | cause?????????? | varchar(255) | NO?? | UNI |???????? |??????????????? | | disabled??????? | tinyint(1)?? | NO?? |???? | 0?????? |??????????????? | +-----------------+--------------+------+-----+---------+----------------+ It seems that Erlang ODBC driver does not support the mysql type varchar? How can I use the database without touching the db schema? Some details about the system env: $ uname -a Linux 2.6.36-gentoo-r8 #4 SMP Thu Apr 7 20:13:18 CST 2011 x86_64 Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz GenuineIntel GNU/Linux $ erl Erlang R13B04 (erts-5.7.5) [source] [64-bit] [smp:2:2] [rq:2] [async-threads:0] [kernel-poll:false] $ emerge -vp erlang dev-lang/erlang-13.2.4? USE="doc kpoll odbc smp ssl -emacs -hipe -java -sctp -tk -wxwidgets" eshell> code:which(odbc). "/usr/lib64/erlang/lib/odbc-2.10.7/ebin/odbc.beam" $ mysql -V mysql? Ver 14.14 Distrib 5.1.51, for pc-linux-gnu (x86_64) using readline 5.1 Server version: 5.1.51-log Gentoo Linux mysql-5.1.51 $ emerge -vp myodbc dev-db/myodbc-5.1.6? USE="-debug -doc -qt4 -static" Any help will be greatly appreciated.? Thanks in advance. Sorry for my poor English, I'm not a native... Best, -- Hanfei From fireflyc@REDACTED Sun May 1 18:37:28 2011 From: fireflyc@REDACTED (=?GB2312?B?0M/JrQ==?=) Date: Mon, 2 May 2011 00:37:28 +0800 Subject: [erlang-questions] gen_server is a single Message-ID: gen_server is a single process? Is there any way to do multi-process? -------------- next part -------------- An HTML attachment was scrubbed... URL: From silent_vendetta@REDACTED Sun May 1 19:37:31 2011 From: silent_vendetta@REDACTED (Chris Hicks) Date: Sun, 1 May 2011 10:37:31 -0700 Subject: [erlang-questions] gen_server is a single In-Reply-To: References: Message-ID: Each gen_server is, indeed, a single process. What you can do, however, is spawn multiple gen_servers under a single supervisor. You can do this by creating a one_for_one or one_for_all supervisor with multiple child specifications, or a simple_one_for_one supervisor and then make multiple calls to supervisor:start_child(Supervisor_name, Args). Either of these methods will give you multiple gen_server processes under a supervision tree, it just depends on exactly what you want to do. I recommend reading up on these following two links: http://www.erlang.org/doc/design_principles/sup_princ.html http://www.erlang.org/doc/man/supervisor.html Chris Hicks. Date: Mon, 2 May 2011 00:37:28 +0800 From: fireflyc@REDACTED To: erlang-questions@REDACTED Subject: [erlang-questions] gen_server is a single gen_server is a single process? Is there any way to do multi-process? _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From kennethstone@REDACTED Sun May 1 19:05:26 2011 From: kennethstone@REDACTED (Kenny Stone) Date: Sun, 1 May 2011 12:05:26 -0500 Subject: [erlang-questions] gen_server is a single In-Reply-To: References: Message-ID: Start a few of them. 2011/5/1 ?? > gen_server is a single process? > > Is there any way to do multi-process? > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vances@REDACTED Sun May 1 19:54:34 2011 From: vances@REDACTED (Vance Shipley) Date: Sun, 1 May 2011 13:54:34 -0400 Subject: [erlang-questions] gen_server is a single In-Reply-To: References: Message-ID: <20110501175433.GY305@h216-235-12-168.host.egate.net> On Mon, May 02, 2011 at 12:37:28AM +0800, ?? wrote: } gen_server is a single process? There is a behaviour named `gen_server' which is implemented in a module with the name `gen_server.erl'. To use it you implement your own callback module. To create a process running the gen_server behaviour with your callback module you call `gen_server:start_link/3,4'. } Is there any way to do multi-process? You may create as many of these processes as you wish. Typically with a server you intend to have other processes call it. If your intent is to use parallel processing to increase the processing capacity you will have to devise a method to distibute the client calls to different server instances. -- -Vance From ixmatus@REDACTED Sun May 1 19:58:25 2011 From: ixmatus@REDACTED (Parnell Springmeyer) Date: Sun, 01 May 2011 10:58:25 -0700 Subject: [erlang-questions] Erlang and MySQL: ODBC, Column type not supported In-Reply-To: (Hanfei Shen's message of "Sun, 1 May 2011 22:32:34 +0800") References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I would recommend using dizzyd's MySQL module: https://github.com/dizzyd/erlang-mysql-driver It works very well for me! Hanfei Shen writes: > Dear all, > > I'm a newbie programming in erlang. When I used ODBC to connect to a > MySQL database through Connector/ODBC (MyODBC), I got some error when > calling odbc:sql_query(Conn, "SELECT * FROM action"): > > {error,"Column type not supported"} > > Then I call odbc:describe_table(Conn, "action"), it returned: > > {ok,[{"id",sql_integer}, > ???? {"code",'ODBC_UNSUPPORTED_TYPE'}, > ???? {"compliment_desc",'ODBC_UNSUPPORTED_TYPE'}, > ???? {"status_desc",'ODBC_UNSUPPORTED_TYPE'}, > ???? {"parameter",'ODBC_UNSUPPORTED_TYPE'}, > ???? {"cause",'ODBC_UNSUPPORTED_TYPE'}, > ???? {"disabled",sql_tinyint}]} > > And desc the table in mysql client: > mysql> desc action; > +-----------------+--------------+------+-----+---------+----------------+ > | Field?????????? | Type???????? | Null | Key | Default | Extra????????? | > +-----------------+--------------+------+-----+---------+----------------+ > | id????????????? | int(11)????? | NO?? | PRI | NULL??? | auto_increment | > | code??????????? | varchar(255) | NO?? |???? | NULL??? |??????????????? | > | compliment_desc | varchar(255) | NO?? |???? |???????? |??????????????? | > | status_desc???? | varchar(255) | NO?? |???? |???????? |??????????????? | > | parameter?????? | varchar(255) | NO?? |???? |???????? |??????????????? | > | cause?????????? | varchar(255) | NO?? | UNI |???????? |??????????????? | > | disabled??????? | tinyint(1)?? | NO?? |???? | 0?????? |??????????????? | > +-----------------+--------------+------+-----+---------+----------------+ > > It seems that Erlang ODBC driver does not support the mysql type > varchar? How can I use the database without touching the db schema? > > > Some details about the system env: > > $ uname -a > Linux 2.6.36-gentoo-r8 #4 SMP Thu Apr 7 20:13:18 CST 2011 x86_64 > Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz GenuineIntel GNU/Linux > > $ erl > Erlang R13B04 (erts-5.7.5) [source] [64-bit] [smp:2:2] [rq:2] > [async-threads:0] [kernel-poll:false] > > $ emerge -vp erlang > dev-lang/erlang-13.2.4? USE="doc kpoll odbc smp ssl -emacs -hipe -java > -sctp -tk -wxwidgets" > > eshell> code:which(odbc). > "/usr/lib64/erlang/lib/odbc-2.10.7/ebin/odbc.beam" > > $ mysql -V > mysql? Ver 14.14 Distrib 5.1.51, for pc-linux-gnu (x86_64) using readline 5.1 > > Server version: 5.1.51-log Gentoo Linux mysql-5.1.51 > > $ emerge -vp myodbc > dev-db/myodbc-5.1.6? USE="-debug -doc -qt4 -static" > > > Any help will be greatly appreciated.? Thanks in advance. > Sorry for my poor English, I'm not a native... > > Best, > > -- > Hanfei > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > - -- Parnell "ixmatus" Springmeyer (http://ixmat.us) -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNvZ9BAAoJEPvtlbpI1POLn3gH/3WPPtfTUSdtEdGCI/kg0Gj9 BOB4vLBId+s5BpFPcm90ZBCkUZccKqT6LTCxMLBZ99w8hlIGXPKafCVO5AMDCZeC /2ZMPW2xHHfseixtYjATj5XG7/6SR1cTsrVhjxvdOPnFNxSXDcW4eZTbJYTWf8Es jSZE6hDTg4DoHLOvOc3UeSw8QiBmLD1nFB0EQM/dcTHuGifygDXztr/0TBBr5VHq yjd2V1BMW0WeSFrHT+mAO8Oh+gtleh0N06R1a5EMCtBDIGmrmy56DciQQirdAjbT NXlpYjHXCbjka1KM0/ov9UWIgw6fhs9EsrKgXpD8pBw0cnYq2Hs7oy5v0M+A0BQ= =Pm6l -----END PGP SIGNATURE----- From dan@REDACTED Sun May 1 21:06:09 2011 From: dan@REDACTED (Daniel Dormont) Date: Sun, 1 May 2011 15:06:09 -0400 Subject: [erlang-questions] Why does fun2ms produce this particular result? Message-ID: I'm trying to get the hang of match specs. Here's a pretty simple one but it has a feature I'm not getting. It's intended for use with Mnesia: 1> rd(person, {name, address, email, phone}). person 2> ets:fun2ms(fun(#person{name=Name, email=Email}) -> {Name, Email} end). [{#person{name = '$1',address = '_',email = '$2', phone = '_'}, [], [{{'$1','$2'}}]}] My first question was going to be why the whole thing is a single-element list, but I think I figured that out: it's because there could be multiple clauses of the match as a whole. The part I don't get is in the result: [{{'$1','$2'}}] 1) Why is it a list at all, since a particular head in the function can only have one result? 2) Why does the tuple have to be wrapped in another tuple? ie why isn't it just {'$1','$2'} For now I'm happy to just trust that fun2ms works, but I'd like to understand it a little better. thanks, Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From freza@REDACTED Sun May 1 21:53:59 2011 From: freza@REDACTED (Jachym Holecek) Date: Sun, 1 May 2011 20:53:59 +0100 Subject: [erlang-questions] Why does fun2ms produce this particular result? In-Reply-To: References: Message-ID: <20110501195359.GA5459@hanele.lan> # Daniel Dormont 2011-05-01: > I'm trying to get the hang of match specs. Here's a pretty simple one but it has a feature I'm not > getting. It's intended for use with Mnesia: > > 1> rd(person, {name, address, email, phone}). > person > 2> ets:fun2ms(fun(#person{name=Name, email=Email}) -> {Name, Email} end). > > [{#person{name = '$1',address = '_',email = '$2', > phone = '_'}, > [], > [{{'$1','$2'}}]}] > > My first question was going to be why the whole thing is a single-element list, but I think I > figured that out: it's because there could be multiple clauses of the match as a whole. Correct. About the rest, http://www.erlang.org/doc/man/ms_transform.html has some information though I'm not sure it's exhaustive. Here's my understanding, I'm sure someone will correct me if I'm wrong (remember that matchspecs aren't just an ETS/Mnesia thing, there's also dbg(3) and there could be other users eventually): > The part I don't get is in the result: [{{'$1','$2'}}] > > 1) Why is it a list at all, since a particular head in the function can only have one result? Because it's a function body (sort of), that is: a sequence of expressions? > 2) Why does the tuple have to be wrapped in another tuple? ie why isn't it just {'$1','$2'} A way of quoting term constructions, to disambiguate them from other constructs in matchspec language (whatever they might be)? > For now I'm happy to just trust that fun2ms works, but I'd like to understand it a little better. To be honest I never tried too hard -- matchspecs are a bit odd, but work great once you get used to them... :-) HTH, -- Jachym From mail@REDACTED Mon May 2 00:01:02 2011 From: mail@REDACTED (Tim Fletcher) Date: Sun, 1 May 2011 15:01:02 -0700 (PDT) Subject: [erlang-questions] more github than Erlang: how do I quickly get to a patch? In-Reply-To: <20110430064137.GA3091@corelatus.se> References: <20110430064137.GA3091@corelatus.se> Message-ID: <7506bc44-7169-4698-9a5e-f20a85b71693@f2g2000yqf.googlegroups.com> > I noticed a post with an interesting fix to Erlang. The link in the mail is: > > ? git fetch git://github.com/falkevik/otp.gitopt_disable_of_flowctrl_for_run_erl_shell > > How I get from the above to seeing a patch, instantly? Link looks broken/incorrect, which wouldn't help. You can get a patch for any commit by appending ".patch" to the commit URL, for example: https://github.com/falkevik/otp/commit/d0775cd6bc64f5eec41d04e04441fe6a6e058927.patch Similarly for diffs: https://github.com/falkevik/otp/commit/d0775cd6bc64f5eec41d04e04441fe6a6e058927.diff Both also work with the compare views. Cheers, Tim From jameschurchman@REDACTED Mon May 2 01:01:49 2011 From: jameschurchman@REDACTED (James Churchman) Date: Mon, 2 May 2011 00:01:49 +0100 Subject: [erlang-questions] byte() vs. char() use in documentation In-Reply-To: <4DB9951A.4050005@cs.ntua.gr> References: <4DB9951A.4050005@cs.ntua.gr> Message-ID: <0C03ACE4-1530-4911-BB56-EDA0BE6BD85A@gmail.com> more of a question than an actual answer, but in erlang can erlang strings ( therefore io-lists) be utf-16? I assume that binaries are obviously only ever utf8 representation, but a list of ints can obviously exceed number above 255.. so maybe (??) the answer is a) iolist CAN be a char() (.. this is surely especially true if the data is only being messages threw erlang from other systems) b) the binary to list are a bit less easy basically it can't be a char(), because it will always have started off as an 8bit ( utf8 ) representation so it will always come back as a list of byte() but in the general case, it's returning an io-list and that can be a char() is this correct? and in that case does that make the bif's xml doc file in fact correct? James On 28 Apr 2011, at 17:26, Kostis Sagonas wrote: > In the Erlang documentation, the language of types and specs makes a clear distinction between the following two types: > > byte() :: 0..255 > char() :: 0..16#10ffff > > See http://erlang.org/doc/reference_manual/typespec.html#id72693 > > I think that nowadays there are very good reasons to have this distinction. > > > In trying to fix a bug today, I happened to notice that some key types of Erlang are inconsistent with this view in the Erlang/OTP documentation (In http://erlang.org/doc/man/erlang.html), most notably: > > iolist() :: [char() | binary() | iolist()] > > binary_to_list(Binary) -> [char()] > binary_to_list(Binary, Start, Stop) -> [char()] > bitstring_to_list(Bitstring) -> [char()|bitstring()] > > and: > > BitstringList :: [BitstringList | bitstring() | char()] > > which actually triggered this mail. > > I think all the occurrences of char() above should read byte() instead. > Right? > > If yes, could somebody at OTP (or some kind volunteer) please clean up this mess? (I can provide a fix for the documentation of the 'erlang' module if you want me to.) > > Kostis > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From masklinn@REDACTED Mon May 2 06:35:17 2011 From: masklinn@REDACTED (Masklinn) Date: Mon, 2 May 2011 06:35:17 +0200 Subject: [erlang-questions] byte() vs. char() use in documentation In-Reply-To: <0C03ACE4-1530-4911-BB56-EDA0BE6BD85A@gmail.com> References: <4DB9951A.4050005@cs.ntua.gr> <0C03ACE4-1530-4911-BB56-EDA0BE6BD85A@gmail.com> Message-ID: <08D996AB-1CA5-4A5F-8D4C-1C232F2E425B@masklinn.net> On 2 mai 2011, at 01:01, James Churchman wrote: > more of a question than an actual answer, but in erlang can erlang strings ( therefore io-lists) be utf-16? > The 16#10ffff upper bound indicates iolists are likely encoded in UCS-4. From t.greenwoodgeer@REDACTED Mon May 2 07:54:57 2011 From: t.greenwoodgeer@REDACTED (Todd) Date: Sun, 01 May 2011 22:54:57 -0700 Subject: [erlang-questions] ets table disappears after bad query Message-ID: <4DBE4731.4030609@gmail.com> I have an ets query that is broken. The funny thing is that after the query fails, the ets table disappears... Here's the code...mostly ripped off from the file doc entry: git://gist.github.com/951214.git REPRO: 1. the ets table does not exist 127> ets:all(). [8207,4110,13,file_io_servers,inet_hosts_file_byaddr, inet_hosts_file_byname,inet_hosts_byaddr,inet_hosts_byname, inet_cache,inet_db,global_pid_ids,global_pid_names, global_names_ext,global_names,global_locks,ac_tab] 128> 2. running the test creates the ets table, 'file_test' dynamic_file:test(). ----------------------------------------- create_file_slow ----------------------------------------- create_file_slow,4884,1024,0.20966420966420968,1, create_file_slow,16569,2048,0.1236043213229525,1, create_file_slow,41857,4096,0.09785698927300093,1, create_file_slow,135915,8192,0.060272964720597434,1, create_file_slow,564260,16384,0.029036259880197073,1, create_file_slow,525989,32768,0.062297880754160255,1, ----------------------------------------- create_file (fast) ----------------------------------------- create_file,13306,1024,0.07695776341500075,1, create_file,2907,1024,0.3522531819745442,2, create_file,1435,1024,0.713588850174216,4, create_file,740,1024,1.3837837837837839,8, ... create_file,468,1024,2.1880341880341883,16, create_file,3132,32768,10.462324393358877,2048, create_file,3556,32768,9.214848143982003,4096, ok 3. verify the ets entry exists (it does) 129> ets:all(). [file_test,8207,4110,13,file_io_servers, inet_hosts_file_byaddr,inet_hosts_file_byname, inet_hosts_byaddr,inet_hosts_byname,inet_cache,inet_db, global_pid_ids,global_pid_names,global_names_ext, global_names,global_locks,ac_tab] 4. run my broken query. i'm trying to sort the results by a specific column so that I can find what block size results in the best performance...not sure yet what's wrong with the query, but i'll figure it out: 130> lists:sort(fun({_,_,_,A,_}, {_,_,_,B,_}) -> A < B end, ets:match(file_test, {create_file, '$0', '$1', '$2', '$3'})). ** exception error: no function clause matching erl_eval:'-inside-an-interpreted-fun-'([13306,1024,0.07695776341500075,1], [2907,1024,0.3522531819745442,2]) 5. look at the ets tables again, and whoa, the 'file_test' table is gone! 131> ets:all(). [8207,4110,13,file_io_servers,inet_hosts_file_byaddr, inet_hosts_file_byname,inet_hosts_byaddr,inet_hosts_byname, inet_cache,inet_db,global_pid_ids,global_pid_names, global_names_ext,global_names,global_locks,ac_tab] 6. Is this expected behaviour? What would I have to do to prevent losing my ets table? -Todd From mazen.harake@REDACTED Mon May 2 08:35:08 2011 From: mazen.harake@REDACTED (Mazen Harake) Date: Mon, 2 May 2011 08:35:08 +0200 Subject: [erlang-questions] Why does fun2ms produce this particular result? In-Reply-To: References: Message-ID: Check out chapter 2 in my dbg tutorial, it describes matchspecs and how to use them. You will also understand what it is that fun2ms actually translates to. http://www.erlang-factory.com/conference/testingtutorialworkshop2010/speakers/MazenHarake Dbg matchspecs aren't exactly like the mnesia ones, there is a small difference but the concept is exactly the same. /M On 1 May 2011 21:06, Daniel Dormont wrote: > I'm trying to get the hang of match specs. Here's a pretty simple one but > it has a feature I'm not getting. It's intended for use with Mnesia: > > 1> rd(person, {name, address, email, phone}). > person > 2> ets:fun2ms(fun(#person{name=Name, email=Email}) -> {Name, Email} > end). > [{#person{name = '$1',address = '_',email = '$2', > phone = '_'}, > [], > [{{'$1','$2'}}]}] > > My first question was going to be why the whole thing is a single-element > list, but I think I figured that out: it's because there could be multiple > clauses of the match as a whole. The part I don't get is in the result: > [{{'$1','$2'}}] > > 1) Why is it a list at all, since a particular head in the function can > only have one result? > 2) Why does the tuple have to be wrapped in another tuple? ie why isn't it > just {'$1','$2'} > > For now I'm happy to just trust that fun2ms works, but I'd like to > understand it a little better. > > thanks, > Dan > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gleber.p@REDACTED Mon May 2 08:48:51 2011 From: gleber.p@REDACTED (Gleb Peregud) Date: Mon, 2 May 2011 08:48:51 +0200 Subject: [erlang-questions] ets table disappears after bad query In-Reply-To: <4DBE4731.4030609@gmail.com> References: <4DBE4731.4030609@gmail.com> Message-ID: Ets table is always linked to some process. When the owner process of a table dies, the table is destroyed. In your case it is linked to shell process. By default shell process dies if any exception happens in the code it runs. BR, Gleb Peregud On 2 May 2011 07:55, "Todd" wrote: > I have an ets query that is broken. The funny thing is that after the > query fails, the ets table disappears... > > Here's the code...mostly ripped off from the file doc entry: > git://gist.github.com/951214.git > > REPRO: > > 1. the ets table does not exist > > 127> ets:all(). > [8207,4110,13,file_io_servers,inet_hosts_file_byaddr, > inet_hosts_file_byname,inet_hosts_byaddr,inet_hosts_byname, > inet_cache,inet_db,global_pid_ids,global_pid_names, > global_names_ext,global_names,global_locks,ac_tab] > 128> > > 2. running the test creates the ets table, 'file_test' > > dynamic_file:test(). > > ----------------------------------------- > create_file_slow > ----------------------------------------- > create_file_slow,4884,1024,0.20966420966420968,1, > create_file_slow,16569,2048,0.1236043213229525,1, > create_file_slow,41857,4096,0.09785698927300093,1, > create_file_slow,135915,8192,0.060272964720597434,1, > create_file_slow,564260,16384,0.029036259880197073,1, > create_file_slow,525989,32768,0.062297880754160255,1, > ----------------------------------------- > create_file (fast) > ----------------------------------------- > create_file,13306,1024,0.07695776341500075,1, > create_file,2907,1024,0.3522531819745442,2, > create_file,1435,1024,0.713588850174216,4, > create_file,740,1024,1.3837837837837839,8, > ... > create_file,468,1024,2.1880341880341883,16, > create_file,3132,32768,10.462324393358877,2048, > create_file,3556,32768,9.214848143982003,4096, > ok > > 3. verify the ets entry exists (it does) > > 129> ets:all(). > [file_test,8207,4110,13,file_io_servers, > inet_hosts_file_byaddr,inet_hosts_file_byname, > inet_hosts_byaddr,inet_hosts_byname,inet_cache,inet_db, > global_pid_ids,global_pid_names,global_names_ext, > global_names,global_locks,ac_tab] > > > 4. run my broken query. i'm trying to sort the results by a specific > column so that I can find what block size results in the best > performance...not sure yet what's wrong with the query, but i'll figure > it out: > > 130> lists:sort(fun({_,_,_,A,_}, {_,_,_,B,_}) -> A < B end, > ets:match(file_test, {create_file, '$0', '$1', '$2', '$3'})). > ** exception error: no function clause matching > erl_eval:'-inside-an-interpreted-fun-'([13306,1024,0.07695776341500075,1], > [2907,1024,0.3522531819745442,2]) > > 5. look at the ets tables again, and whoa, the 'file_test' table is gone! > > 131> > ets:all(). > > [8207,4110,13,file_io_servers,inet_hosts_file_byaddr, > inet_hosts_file_byname,inet_hosts_byaddr,inet_hosts_byname, > inet_cache,inet_db,global_pid_ids,global_pid_names, > global_names_ext,global_names,global_locks,ac_tab] > > 6. Is this expected behaviour? What would I have to do to prevent losing > my ets table? > > -Todd > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From monch1962@REDACTED Mon May 2 08:56:28 2011 From: monch1962@REDACTED (David Mitchell) Date: Mon, 2 May 2011 16:56:28 +1000 Subject: [erlang-questions] Using CouchDB to hold state for FSM - pros and cons? Message-ID: Hi all, I've got to build an enormous finite state machine (FSM) to hold state for tens of thousands of in-flight transactions. The various state transitions aren't well known yet; all I know is there's going to be lots of state transactions per transaction, transaction volume will be extremely high, and I'll probably have a bare minimum of time to throw together a working solution ;-> In the past I've used mnesia to hold transaction state for similar projects, but I've read a few articles about problems with it scaling and have a bit of a concern on that count for this particular project. I've been using CouchDB for a few unrelated projects recently, and have been impressed with it on every score - on the surface it seems to be a good fit for my specific problem. However I haven't stumbled on anybody using CouchDB as a high throughput, transitional data store - everything I've read about it has involved CouchDB working more or less as a NoSQL version of a "traditional" write-once, read-often data store. My application is far more "write-once, update-many-times-very-quickly, delete" from a data perspective. Has anyone used CouchDB as a FSM data store in a similar project in the past? Pros and cons? Any tips or suggestions? Thanks in advance David Mitchell -------------- next part -------------- An HTML attachment was scrubbed... URL: From ingela@REDACTED Mon May 2 08:58:43 2011 From: ingela@REDACTED (Ingela Andin) Date: Mon, 2 May 2011 08:58:43 +0200 Subject: [erlang-questions] Erlang and MySQL: ODBC, Column type not supported In-Reply-To: References: Message-ID: Hi! The erlang odbc application supports {sql-varchars, N} where N = 255 in your case. The return values you get suggest that the odbc-driver you have returns an unexpected column type. In the erlang odbc port program there is a switch that handles type when describing a coloumn that if we take out the handling code looks like this. switch(sql_type) { case SQL_CHAR: case SQL_VARCHAR: case SQL_WCHAR: case SQL_WVARCHAR: case SQL_NUMERIC: case SQL_DECIMAL: case SQL_INTEGER: case SQL_TINYINT: case SQL_SMALLINT: case SQL_REAL: case SQL_FLOAT: case SQL_DOUBLE: case SQL_BIT: case SQL_TYPE_DATE: case SQL_TYPE_TIME: case SQL_TYPE_TIMESTAMP: case SQL_BIGINT: case SQL_BINARY: case SQL_LONGVARCHAR: case SQL_VARBINARY: case SQL_LONGVARBINARY: case SQL_INTERVAL_MONTH: case SQL_INTERVAL_YEAR: case SQL_INTERVAL_DAY: case SQL_INTERVAL_MINUTE: case SQL_INTERVAL_HOUR_TO_SECOND: case SQL_INTERVAL_MINUTE_TO_SECOND: case SQL_UNKNOWN_TYPE: default: /* Will probably never happen */ ei_x_encode_atom(&dynamic_buffer(state), "ODBC_UNSUPPORTED_TYPE"); break; } And you end up in the default clause which is very unexpected and the root to your problem. If you can figur out what your driver returns for the ODBC C-API function SQLDescribeCol we could know if the driver is at fault or if the odbc-port program is. Regards Ingela Erlang/OTP team - Ericsson AB 2011/5/1 Hanfei Shen : > Dear all, > > I'm a newbie programming in erlang. When I used ODBC to connect to a > MySQL database through Connector/ODBC (MyODBC), I got some error when > calling odbc:sql_query(Conn, "SELECT * FROM action"): > > {error,"Column type not supported"} > > Then I call odbc:describe_table(Conn, "action"), it returned: > > {ok,[{"id",sql_integer}, > ???? {"code",'ODBC_UNSUPPORTED_TYPE'}, > ???? {"compliment_desc",'ODBC_UNSUPPORTED_TYPE'}, > ???? {"status_desc",'ODBC_UNSUPPORTED_TYPE'}, > ???? {"parameter",'ODBC_UNSUPPORTED_TYPE'}, > ???? {"cause",'ODBC_UNSUPPORTED_TYPE'}, > ???? {"disabled",sql_tinyint}]} > > And desc the table in mysql client: > mysql> desc action; > +-----------------+--------------+------+-----+---------+----------------+ > | Field?????????? | Type???????? | Null | Key | Default | Extra????????? | > +-----------------+--------------+------+-----+---------+----------------+ > | id????????????? | int(11)????? | NO?? | PRI | NULL??? | auto_increment | > | code??????????? | varchar(255) | NO?? |???? | NULL??? |??????????????? | > | compliment_desc | varchar(255) | NO?? |???? |???????? |??????????????? | > | status_desc???? | varchar(255) | NO?? |???? |???????? |??????????????? | > | parameter?????? | varchar(255) | NO?? |???? |???????? |??????????????? | > | cause?????????? | varchar(255) | NO?? | UNI |???????? |??????????????? | > | disabled??????? | tinyint(1)?? | NO?? |???? | 0?????? |??????????????? | > +-----------------+--------------+------+-----+---------+----------------+ > > It seems that Erlang ODBC driver does not support the mysql type > varchar? How can I use the database without touching the db schema? > > > Some details about the system env: > > $ uname -a > Linux 2.6.36-gentoo-r8 #4 SMP Thu Apr 7 20:13:18 CST 2011 x86_64 > Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz GenuineIntel GNU/Linux > > $ erl > Erlang R13B04 (erts-5.7.5) [source] [64-bit] [smp:2:2] [rq:2] > [async-threads:0] [kernel-poll:false] > > $ emerge -vp erlang > dev-lang/erlang-13.2.4? USE="doc kpoll odbc smp ssl -emacs -hipe -java > -sctp -tk -wxwidgets" > > eshell> code:which(odbc). > "/usr/lib64/erlang/lib/odbc-2.10.7/ebin/odbc.beam" > > $ mysql -V > mysql? Ver 14.14 Distrib 5.1.51, for pc-linux-gnu (x86_64) using readline 5.1 > > Server version: 5.1.51-log Gentoo Linux mysql-5.1.51 > > $ emerge -vp myodbc > dev-db/myodbc-5.1.6? USE="-debug -doc -qt4 -static" > > > Any help will be greatly appreciated.? Thanks in advance. > Sorry for my poor English, I'm not a native... > > Best, > > -- > Hanfei > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From nick.sfx.1@REDACTED Mon May 2 09:16:46 2011 From: nick.sfx.1@REDACTED (Nick S) Date: Mon, 2 May 2011 07:16:46 +0000 Subject: [erlang-questions] Which OS for best server performance? Message-ID: Which OS performs best in running Erlang based server (built using several OTP components), involved in reading and processing high number of socket messages. And of course I am referring to BSD and Linux likes, and want to utilize full power of multi-core CPUs. Any thoughts on DragonFly BSD, a fork from FreeBSD 4.8 aiming for a different multiprocessor synchronization strategy (from wikipedia!). From erlang@REDACTED Mon May 2 09:52:22 2011 From: erlang@REDACTED (Joe Armstrong) Date: Mon, 2 May 2011 09:52:22 +0200 Subject: [erlang-questions] Using CouchDB to hold state for FSM - pros and cons? In-Reply-To: References: Message-ID: You haven't sent enough information to make a reasonable judgment. what is "lots" in the phrase "lots of state transactions per transaction" - 10? 1000? 10^10 what is "high" in "extremely high" You need to quantity words like "lots" and "high" with numbers or ranges of numbers How many transactions/second? How many simultaneous sessions? How large is the state Do you want the fault-tolerance? What are the latency requirements Up-time requirements and so on. Sounds to me like you want a fault-tolerant low-latency key-value store. CouchDb will store all the data forever, which is probably not what you want. Scalaris or Riak sounds like a better fit. /Joe On Mon, May 2, 2011 at 8:56 AM, David Mitchell wrote: > Hi all, > > I've got to build an enormous finite state machine (FSM) to hold state for > tens of thousands of in-flight transactions. The various state transitions > aren't well known yet; all I know is there's going to be lots of state > transactions per transaction, transaction volume will be extremely high, and > I'll probably have a bare minimum of time to throw together a working > solution ;-> > > In the past I've used mnesia to hold transaction state for similar > projects, but I've read a few articles about problems with it scaling and > have a bit of a concern on that count for this particular project. I've > been using CouchDB for a few unrelated projects recently, and have been > impressed with it on every score - on the surface it seems to be a good fit > for my specific problem. However I haven't stumbled on anybody using > CouchDB as a high throughput, transitional data store - everything I've read > about it has involved CouchDB working more or less as a NoSQL version of a > "traditional" write-once, read-often data store. > > My application is far more "write-once, update-many-times-very-quickly, > delete" from a data perspective. > > Has anyone used CouchDB as a FSM data store in a similar project in the > past? Pros and cons? Any tips or suggestions? > > Thanks in advance > > David Mitchell > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From qqshfox@REDACTED Mon May 2 10:21:18 2011 From: qqshfox@REDACTED (Hanfei Shen) Date: Mon, 2 May 2011 16:21:18 +0800 Subject: [erlang-questions] Erlang and MySQL: ODBC, Column type not supported In-Reply-To: References: Message-ID: Hi Parnell, The module which you recommended does work correctly, but I wonder why erlang odbc/MyODBC does not support such a common column type... Thank you very much indeed. 2011/5/2 Parnell Springmeyer : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I would recommend using dizzyd's MySQL module: > > https://github.com/dizzyd/erlang-mysql-driver > > It works very well for me! > > Hanfei Shen writes: > >> Dear all, >> >> I'm a newbie programming in erlang. When I used ODBC to connect to a >> MySQL database through Connector/ODBC (MyODBC), I got some error when >> calling odbc:sql_query(Conn, "SELECT * FROM action"): >> >> {error,"Column type not supported"} >> >> Then I call odbc:describe_table(Conn, "action"), it returned: >> >> {ok,[{"id",sql_integer}, >> ???? {"code",'ODBC_UNSUPPORTED_TYPE'}, >> ???? {"compliment_desc",'ODBC_UNSUPPORTED_TYPE'}, >> ???? {"status_desc",'ODBC_UNSUPPORTED_TYPE'}, >> ???? {"parameter",'ODBC_UNSUPPORTED_TYPE'}, >> ???? {"cause",'ODBC_UNSUPPORTED_TYPE'}, >> ???? {"disabled",sql_tinyint}]} >> >> And desc the table in mysql client: >> mysql> desc action; >> +-----------------+--------------+------+-----+---------+----------------+ >> | Field?????????? | Type???????? | Null | Key | Default | Extra????????? | >> +-----------------+--------------+------+-----+---------+----------------+ >> | id????????????? | int(11)????? | NO?? | PRI | NULL??? | auto_increment | >> | code??????????? | varchar(255) | NO?? |???? | NULL??? |??????????????? | >> | compliment_desc | varchar(255) | NO?? |???? |???????? |??????????????? | >> | status_desc???? | varchar(255) | NO?? |???? |???????? |??????????????? | >> | parameter?????? | varchar(255) | NO?? |???? |???????? |??????????????? | >> | cause?????????? | varchar(255) | NO?? | UNI |???????? |??????????????? | >> | disabled??????? | tinyint(1)?? | NO?? |???? | 0?????? |??????????????? | >> +-----------------+--------------+------+-----+---------+----------------+ >> >> It seems that Erlang ODBC driver does not support the mysql type >> varchar? How can I use the database without touching the db schema? >> >> >> Some details about the system env: >> >> $ uname -a >> Linux 2.6.36-gentoo-r8 #4 SMP Thu Apr 7 20:13:18 CST 2011 x86_64 >> Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz GenuineIntel GNU/Linux >> >> $ erl >> Erlang R13B04 (erts-5.7.5) [source] [64-bit] [smp:2:2] [rq:2] >> [async-threads:0] [kernel-poll:false] >> >> $ emerge -vp erlang >> dev-lang/erlang-13.2.4? USE="doc kpoll odbc smp ssl -emacs -hipe -java >> -sctp -tk -wxwidgets" >> >> eshell> code:which(odbc). >> "/usr/lib64/erlang/lib/odbc-2.10.7/ebin/odbc.beam" >> >> $ mysql -V >> mysql? Ver 14.14 Distrib 5.1.51, for pc-linux-gnu (x86_64) using readline 5.1 >> >> Server version: 5.1.51-log Gentoo Linux mysql-5.1.51 >> >> $ emerge -vp myodbc >> dev-db/myodbc-5.1.6? USE="-debug -doc -qt4 -static" >> >> >> Any help will be greatly appreciated.? Thanks in advance. >> Sorry for my poor English, I'm not a native... >> >> Best, >> >> -- >> Hanfei >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > - -- > Parnell "ixmatus" Springmeyer (http://ixmat.us) > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > > iQEcBAEBAgAGBQJNvZ9BAAoJEPvtlbpI1POLn3gH/3WPPtfTUSdtEdGCI/kg0Gj9 > BOB4vLBId+s5BpFPcm90ZBCkUZccKqT6LTCxMLBZ99w8hlIGXPKafCVO5AMDCZeC > /2ZMPW2xHHfseixtYjATj5XG7/6SR1cTsrVhjxvdOPnFNxSXDcW4eZTbJYTWf8Es > jSZE6hDTg4DoHLOvOc3UeSw8QiBmLD1nFB0EQM/dcTHuGifygDXztr/0TBBr5VHq > yjd2V1BMW0WeSFrHT+mAO8Oh+gtleh0N06R1a5EMCtBDIGmrmy56DciQQirdAjbT > NXlpYjHXCbjka1KM0/ov9UWIgw6fhs9EsrKgXpD8pBw0cnYq2Hs7oy5v0M+A0BQ= > =Pm6l > -----END PGP SIGNATURE----- > From qqshfox@REDACTED Mon May 2 10:29:23 2011 From: qqshfox@REDACTED (Hanfei Shen) Date: Mon, 2 May 2011 16:29:23 +0800 Subject: [erlang-questions] Erlang and MySQL: ODBC, Column type not supported In-Reply-To: References: Message-ID: Hi Ingela, Did you mean the value of variable "sql_type"? I tried to inspect it through gdb, setting a break on func encode_data_type. And then I got: Breakpoint 1, encode_data_type (sql_type=-9, size=255, decimal_digits=0, state=0x7fffc657ec40) at odbcserver.c:1396 1396 switch(sql_type) { 2011/5/2 Ingela Andin : > Hi! > > The erlang odbc application supports {sql-varchars, ?N} where N = 255 > in your case. The return values > you get suggest that the odbc-driver you have returns an unexpected column type. > > In the erlang odbc port program there is a switch that handles type > when describing a coloumn that if we take out > the handling code looks like this. > > switch(sql_type) { > ? ?case SQL_CHAR: > ? ?case SQL_VARCHAR: > ? ?case SQL_WCHAR: > ? ?case SQL_WVARCHAR: > ? ?case SQL_NUMERIC: > ? ?case SQL_DECIMAL: > ? ?case SQL_INTEGER: > ? ?case SQL_TINYINT: > ? ?case SQL_SMALLINT: > ? ?case SQL_REAL: > ? ?case SQL_FLOAT: > ? ?case SQL_DOUBLE: > ? ?case SQL_BIT: > ? ?case SQL_TYPE_DATE: > ? ?case SQL_TYPE_TIME: > ? ?case SQL_TYPE_TIMESTAMP: > ? ?case SQL_BIGINT: > ? ?case SQL_BINARY: > ? ?case SQL_LONGVARCHAR: > ? ?case SQL_VARBINARY: > ? ?case SQL_LONGVARBINARY: > ? ?case SQL_INTERVAL_MONTH: > ? ?case SQL_INTERVAL_YEAR: > ? ?case SQL_INTERVAL_DAY: > ? ?case SQL_INTERVAL_MINUTE: > ? ?case SQL_INTERVAL_HOUR_TO_SECOND: > ? ?case SQL_INTERVAL_MINUTE_TO_SECOND: > ? ?case SQL_UNKNOWN_TYPE: > ? ?default: /* Will probably never happen */ > ? ? ? ?ei_x_encode_atom(&dynamic_buffer(state), "ODBC_UNSUPPORTED_TYPE"); > ? ? ? ?break; > ? ?} > > > And you end up in the default clause which is very unexpected and the > root to your problem. ?If ?you can figur out > what your driver returns for the ODBC C-API function SQLDescribeCol we > could know if the driver is at fault or if the odbc-port program is. > > Regards ?Ingela Erlang/OTP team - Ericsson AB > > 2011/5/1 Hanfei Shen : >> Dear all, >> >> I'm a newbie programming in erlang. When I used ODBC to connect to a >> MySQL database through Connector/ODBC (MyODBC), I got some error when >> calling odbc:sql_query(Conn, "SELECT * FROM action"): >> >> {error,"Column type not supported"} >> >> Then I call odbc:describe_table(Conn, "action"), it returned: >> >> {ok,[{"id",sql_integer}, >> ???? {"code",'ODBC_UNSUPPORTED_TYPE'}, >> ???? {"compliment_desc",'ODBC_UNSUPPORTED_TYPE'}, >> ???? {"status_desc",'ODBC_UNSUPPORTED_TYPE'}, >> ???? {"parameter",'ODBC_UNSUPPORTED_TYPE'}, >> ???? {"cause",'ODBC_UNSUPPORTED_TYPE'}, >> ???? {"disabled",sql_tinyint}]} >> >> And desc the table in mysql client: >> mysql> desc action; >> +-----------------+--------------+------+-----+---------+----------------+ >> | Field?????????? | Type???????? | Null | Key | Default | Extra????????? | >> +-----------------+--------------+------+-----+---------+----------------+ >> | id????????????? | int(11)????? | NO?? | PRI | NULL??? | auto_increment | >> | code??????????? | varchar(255) | NO?? |???? | NULL??? |??????????????? | >> | compliment_desc | varchar(255) | NO?? |???? |???????? |??????????????? | >> | status_desc???? | varchar(255) | NO?? |???? |???????? |??????????????? | >> | parameter?????? | varchar(255) | NO?? |???? |???????? |??????????????? | >> | cause?????????? | varchar(255) | NO?? | UNI |???????? |??????????????? | >> | disabled??????? | tinyint(1)?? | NO?? |???? | 0?????? |??????????????? | >> +-----------------+--------------+------+-----+---------+----------------+ >> >> It seems that Erlang ODBC driver does not support the mysql type >> varchar? How can I use the database without touching the db schema? >> >> >> Some details about the system env: >> >> $ uname -a >> Linux 2.6.36-gentoo-r8 #4 SMP Thu Apr 7 20:13:18 CST 2011 x86_64 >> Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz GenuineIntel GNU/Linux >> >> $ erl >> Erlang R13B04 (erts-5.7.5) [source] [64-bit] [smp:2:2] [rq:2] >> [async-threads:0] [kernel-poll:false] >> >> $ emerge -vp erlang >> dev-lang/erlang-13.2.4? USE="doc kpoll odbc smp ssl -emacs -hipe -java >> -sctp -tk -wxwidgets" >> >> eshell> code:which(odbc). >> "/usr/lib64/erlang/lib/odbc-2.10.7/ebin/odbc.beam" >> >> $ mysql -V >> mysql? Ver 14.14 Distrib 5.1.51, for pc-linux-gnu (x86_64) using readline 5.1 >> >> Server version: 5.1.51-log Gentoo Linux mysql-5.1.51 >> >> $ emerge -vp myodbc >> dev-db/myodbc-5.1.6? USE="-debug -doc -qt4 -static" >> >> >> Any help will be greatly appreciated.? Thanks in advance. >> Sorry for my poor English, I'm not a native... >> >> Best, >> >> -- >> Hanfei >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > From carlo.bertoldi@REDACTED Mon May 2 10:34:43 2011 From: carlo.bertoldi@REDACTED (Carlo Bertoldi) Date: Mon, 02 May 2011 10:34:43 +0200 Subject: [erlang-questions] ets table disappears after bad query In-Reply-To: <4DBE4731.4030609@gmail.com> References: <4DBE4731.4030609@gmail.com> Message-ID: <4DBE6CA3.3000109@ubiquity.it> On 02/05/2011 07:54, Todd wrote: > I have an ets query that is broken. The funny thing is that after the > query fails, the ets table disappears... > > 6. Is this expected behaviour? What would I have to do to prevent > losing my ets table? > Yes. To avoid this you should create the table in a process, start it without linking to it, and then run you query. Then the crash due to the wrong query shouldn't bring down you ets. Carlo > -Todd From ulf.wiger@REDACTED Mon May 2 10:37:37 2011 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Mon, 2 May 2011 10:37:37 +0200 Subject: [erlang-questions] Using CouchDB to hold state for FSM - pros and cons? In-Reply-To: References: Message-ID: <98D2F268-124B-4E5B-AA9E-E09BC1796ED2@erlang-solutions.com> Another piece of information that would be good to know is: what are the persistency requirements? Is there a need for state to survive system crashes/restarts? Is there a need for redundancy at all? If there is no need for persistency, Erlang has a wonderful model for holding FSM state - a process per FSM. Keeping tens of thousand processes in one erlang node is no problem whatsoever. Keeping track of tens of thousand live processes used to be a problem, but that was why gproc was created, and it works very well as a process "index". Various requirements on fault tolerance may make this model impractical. Speed or data volume requirements* may also drive towards a different solution, quite often in conflicting ways, so as Joe says, it's important to be specific - also about which tradeoffs are acceptable. BR, Ulf W On 2 May 2011, at 09:52, Joe Armstrong wrote: > You haven't sent enough information to make a reasonable judgment. > > what is "lots" in the phrase "lots of state transactions per transaction" - 10? 1000? 10^10 > what is "high" in "extremely high" > > You need to quantity words like "lots" and "high" with numbers or ranges of numbers > > How many transactions/second? > How many simultaneous sessions? > How large is the state > Do you want the fault-tolerance? > What are the latency requirements > Up-time requirements > > and so on. > > Sounds to me like you want a fault-tolerant low-latency key-value store. > > CouchDb will store all the data forever, which is probably not what you want. Scalaris or Riak > sounds like a better fit. > > /Joe > > > On Mon, May 2, 2011 at 8:56 AM, David Mitchell wrote: > Hi all, > > I've got to build an enormous finite state machine (FSM) to hold state for tens of thousands of in-flight transactions. The various state transitions aren't well known yet; all I know is there's going to be lots of state transactions per transaction, transaction volume will be extremely high, and I'll probably have a bare minimum of time to throw together a working solution ;-> > > In the past I've used mnesia to hold transaction state for similar projects, but I've read a few articles about problems with it scaling and have a bit of a concern on that count for this particular project. I've been using CouchDB for a few unrelated projects recently, and have been impressed with it on every score - on the surface it seems to be a good fit for my specific problem. However I haven't stumbled on anybody using CouchDB as a high throughput, transitional data store - everything I've read about it has involved CouchDB working more or less as a NoSQL version of a "traditional" write-once, read-often data store. > > My application is far more "write-once, update-many-times-very-quickly, delete" from a data perspective. > > Has anyone used CouchDB as a FSM data store in a similar project in the past? Pros and cons? Any tips or suggestions? > > Thanks in advance > > David Mitchell > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions Ulf Wiger, CTO, Erlang Solutions, Ltd. http://erlang-solutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From masklinn@REDACTED Mon May 2 10:51:57 2011 From: masklinn@REDACTED (Masklinn) Date: Mon, 2 May 2011 10:51:57 +0200 Subject: [erlang-questions] ets table disappears after bad query In-Reply-To: <4DBE6CA3.3000109@ubiquity.it> References: <4DBE4731.4030609@gmail.com> <4DBE6CA3.3000109@ubiquity.it> Message-ID: On 2 mai 2011, at 10:34, Carlo Bertoldi wrote: > On 02/05/2011 07:54, Todd wrote: >> I have an ets query that is broken. The funny thing is that after the query fails, the ets table disappears... >> >> 6. Is this expected behaviour? What would I have to do to prevent losing my ets table? >> > Yes. To avoid this you should create the table in a process, start it without linking to it, and then run you query. > Then the crash due to the wrong query shouldn't bring down you ets. > An other alternative would be to declare an other process as the table's owner and the shell process as inheritor. That way, the owner process dies on a bad query, the shell gets the intact table back and can just create a new sacrificial process to own the table for the next query. From carlo.bertoldi@REDACTED Mon May 2 11:07:25 2011 From: carlo.bertoldi@REDACTED (Carlo Bertoldi) Date: Mon, 02 May 2011 11:07:25 +0200 Subject: [erlang-questions] Dialyzer Message-ID: <4DBE744D.5060909@ubiquity.it> Hello list, this is a bad monday, and I'm stuck with this warning from dialyzer: The specification for change_interval/2 states that the function might also return [any()] but the inferred return is none() The code: -spec(change_interval(integer(), [term()]) -> [term()]). change_interval(NewInterval, Config) -> NewPause = {pause, NewInterval}, NewConfig = lists:keyreplace(pause, 1, Config, NewPause), write_config(NewPause), NewConfig. Config is a list of terms, built using file:consult. I googled a bit, and I understand that this is a common problem, but it really goes over my head. What am I missing? Carlo From raimo+erlang-questions@REDACTED Mon May 2 11:14:15 2011 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Mon, 2 May 2011 11:14:15 +0200 Subject: [erlang-questions] byte() vs. char() use in documentation In-Reply-To: <0C03ACE4-1530-4911-BB56-EDA0BE6BD85A@gmail.com> References: <4DB9951A.4050005@cs.ntua.gr> <0C03ACE4-1530-4911-BB56-EDA0BE6BD85A@gmail.com> Message-ID: <20110502091415.GA6512@erix.ericsson.se> On Mon, May 02, 2011 at 12:01:49AM +0100, James Churchman wrote: > more of a question than an actual answer, but in erlang can erlang strings ( therefore io-lists) be utf-16? A string is a list of unicode code points. An IO-list is a list of binaries or bytes. > > I assume that binaries are obviously only ever utf8 representation, but a list of ints can obviously exceed number above 255.. You can choose your binary representation. See erlang man page unicode(3). > > so maybe (??) the answer is > > a) iolist CAN be a char() (.. this is surely especially true if the data is only being messages threw erlang from other systems) No. byte(). > > b) the binary to list are a bit less easy Compare erlang:binary_to_list/1 and erlang:list_to_binary/1 with the corresponding functions in module 'unicode'. > > basically it can't be a char(), because it will always have started off as an 8bit ( utf8 ) representation so it will always come back as a list of byte() but in the general case, it's returning an io-list and that can be a char() > > is this correct? and in that case does that make the bif's xml doc file in fact correct? The documentation is incorrect. Once there was no difference between char() and byte(). char() ment a ISO-8859-1 character which is the same size as byte(). > > James > > On 28 Apr 2011, at 17:26, Kostis Sagonas wrote: > > > In the Erlang documentation, the language of types and specs makes a clear distinction between the following two types: > > > > byte() :: 0..255 > > char() :: 0..16#10ffff > > > > See http://erlang.org/doc/reference_manual/typespec.html#id72693 > > > > I think that nowadays there are very good reasons to have this distinction. > > > > > > In trying to fix a bug today, I happened to notice that some key types of Erlang are inconsistent with this view in the Erlang/OTP documentation (In http://erlang.org/doc/man/erlang.html), most notably: > > > > iolist() :: [char() | binary() | iolist()] > > > > binary_to_list(Binary) -> [char()] > > binary_to_list(Binary, Start, Stop) -> [char()] > > bitstring_to_list(Bitstring) -> [char()|bitstring()] > > > > and: > > > > BitstringList :: [BitstringList | bitstring() | char()] > > > > which actually triggered this mail. > > > > I think all the occurrences of char() above should read byte() instead. > > Right? > > > > If yes, could somebody at OTP (or some kind volunteer) please clean up this mess? (I can provide a fix for the documentation of the 'erlang' module if you want me to.) > > > > Kostis > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From kostis@REDACTED Mon May 2 11:23:57 2011 From: kostis@REDACTED (Kostis Sagonas) Date: Mon, 02 May 2011 12:23:57 +0300 Subject: [erlang-questions] Dialyzer In-Reply-To: <4DBE744D.5060909@ubiquity.it> References: <4DBE744D.5060909@ubiquity.it> Message-ID: <4DBE782D.80300@cs.ntua.gr> Carlo Bertoldi wrote: > Hello list, > this is a bad monday, and I'm stuck with this warning from dialyzer: > > The specification for change_interval/2 states that the function might > also return [any()] but the inferred return is none() > > The code: > -spec(change_interval(integer(), [term()]) -> [term()]). > > change_interval(NewInterval, Config) -> > NewPause = {pause, NewInterval}, > NewConfig = lists:keyreplace(pause, 1, Config, NewPause), > write_config(NewPause), > NewConfig. > > Config is a list of terms, built using file:consult. > I googled a bit, and I understand that this is a common problem, but it > really goes over my head. > What am I missing? I do not know what you are missing, but it's pretty obvious that the code you've given us is missing quite a lot... For starters, it does not include function write_config/1 so it cannot be compiled. Second, you claim that Config is a list of terms built somehow but you do not show us that code. If you want help in finding out what the problem is, please post a (preferably minimal) module that shows the symptoms you are experiencing. Also, which dialyzer version is this? Kostis From robert.virding@REDACTED Mon May 2 11:35:18 2011 From: robert.virding@REDACTED (Robert Virding) Date: Mon, 2 May 2011 09:35:18 +0000 (GMT) Subject: [erlang-questions] byte() vs. char() use in documentation In-Reply-To: <20110502091415.GA6512@erix.ericsson.se> Message-ID: <372726991.139721304328918708.JavaMail.root@zimbra> ----- "Raimo Niskanen" wrote: > On Mon, May 02, 2011 at 12:01:49AM +0100, James Churchman wrote: > > more of a question than an actual answer, but in erlang can erlang > strings ( therefore io-lists) be utf-16? > > A string is a list of unicode code points. > > An IO-list is a list of binaries or bytes. > > > > > I assume that binaries are obviously only ever utf8 representation, > but a list of ints can obviously exceed number above 255.. > > You can choose your binary representation. See erlang man page > unicode(3). > > > > > so maybe (??) the answer is > > > > a) iolist CAN be a char() (.. this is surely especially true if the > data is only being messages threw erlang from other systems) > > No. byte(). As a string is a list of unicode code points and an iolist can contain a string then its type must also be char(). Robert From alex.arnon@REDACTED Mon May 2 11:36:59 2011 From: alex.arnon@REDACTED (Alex Arnon) Date: Mon, 2 May 2011 12:36:59 +0300 Subject: [erlang-questions] Which OS for best server performance? In-Reply-To: References: Message-ID: <6C7AAB47-5686-45C3-B477-65642ADB4EFD@gmail.com> I would look at FreeBSD - and Solaris, actually. Both are very scalable, with Solaris being the higher-end of the two. Any commonly-used server Linus distro should also be good: Debian, CentOS and the Enterprise ones. On 2 May 2011, at 10:16, Nick S wrote: > Which OS performs best in running Erlang based server (built using > several OTP components), involved in reading and processing high > number of socket messages. > > And of course I am referring to BSD and Linux likes, and want to > utilize full power of multi-core CPUs. > > Any thoughts on DragonFly BSD, a fork from FreeBSD 4.8 aiming for a > different multiprocessor synchronization strategy (from wikipedia!). > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From ingela@REDACTED Mon May 2 11:37:13 2011 From: ingela@REDACTED (Ingela Anderton Andin) Date: Mon, 2 May 2011 11:37:13 +0200 Subject: [erlang-questions] Erlang and MySQL: ODBC, Column type not supported In-Reply-To: References: Message-ID: <4DBE7B49.1080505@erix.ericsson.se> Hi! Hanfei Shen wrote: > Hi Ingela, > > Did you mean the value of variable "sql_type"? > > Yes. > I tried to inspect it through gdb, setting a break on func > encode_data_type. And then I got: > > Breakpoint 1, encode_data_type (sql_type=-9, size=255, > decimal_digits=0, state=0x7fffc657ec40) at odbcserver.c:1396 > 1396 switch(sql_type) { > > Well that is defenetly not a good value. Looking at the code just now I noticed that encode_data_type defines sql_type as "SQLINTEGER sql_type" and it ought to be "SQLSMALLINT sql_type". If you change that does it fix your problem? Regards Ingela Erlang/OTP team - Ericsson AB > 2011/5/2 Ingela Andin : > >> Hi! >> >> The erlang odbc application supports {sql-varchars, N} where N = 255 >> in your case. The return values >> you get suggest that the odbc-driver you have returns an unexpected column type. >> >> In the erlang odbc port program there is a switch that handles type >> when describing a coloumn that if we take out >> the handling code looks like this. >> >> switch(sql_type) { >> case SQL_CHAR: >> case SQL_VARCHAR: >> case SQL_WCHAR: >> case SQL_WVARCHAR: >> case SQL_NUMERIC: >> case SQL_DECIMAL: >> case SQL_INTEGER: >> case SQL_TINYINT: >> case SQL_SMALLINT: >> case SQL_REAL: >> case SQL_FLOAT: >> case SQL_DOUBLE: >> case SQL_BIT: >> case SQL_TYPE_DATE: >> case SQL_TYPE_TIME: >> case SQL_TYPE_TIMESTAMP: >> case SQL_BIGINT: >> case SQL_BINARY: >> case SQL_LONGVARCHAR: >> case SQL_VARBINARY: >> case SQL_LONGVARBINARY: >> case SQL_INTERVAL_MONTH: >> case SQL_INTERVAL_YEAR: >> case SQL_INTERVAL_DAY: >> case SQL_INTERVAL_MINUTE: >> case SQL_INTERVAL_HOUR_TO_SECOND: >> case SQL_INTERVAL_MINUTE_TO_SECOND: >> case SQL_UNKNOWN_TYPE: >> default: /* Will probably never happen */ >> ei_x_encode_atom(&dynamic_buffer(state), "ODBC_UNSUPPORTED_TYPE"); >> break; >> } >> >> >> And you end up in the default clause which is very unexpected and the >> root to your problem. If you can figur out >> what your driver returns for the ODBC C-API function SQLDescribeCol we >> could know if the driver is at fault or if the odbc-port program is. >> >> Regards Ingela Erlang/OTP team - Ericsson AB >> >> 2011/5/1 Hanfei Shen : >> >>> Dear all, >>> >>> I'm a newbie programming in erlang. When I used ODBC to connect to a >>> MySQL database through Connector/ODBC (MyODBC), I got some error when >>> calling odbc:sql_query(Conn, "SELECT * FROM action"): >>> >>> {error,"Column type not supported"} >>> >>> Then I call odbc:describe_table(Conn, "action"), it returned: >>> >>> {ok,[{"id",sql_integer}, >>> {"code",'ODBC_UNSUPPORTED_TYPE'}, >>> {"compliment_desc",'ODBC_UNSUPPORTED_TYPE'}, >>> {"status_desc",'ODBC_UNSUPPORTED_TYPE'}, >>> {"parameter",'ODBC_UNSUPPORTED_TYPE'}, >>> {"cause",'ODBC_UNSUPPORTED_TYPE'}, >>> {"disabled",sql_tinyint}]} >>> >>> And desc the table in mysql client: >>> mysql> desc action; >>> +-----------------+--------------+------+-----+---------+----------------+ >>> | Field | Type | Null | Key | Default | Extra | >>> +-----------------+--------------+------+-----+---------+----------------+ >>> | id | int(11) | NO | PRI | NULL | auto_increment | >>> | code | varchar(255) | NO | | NULL | | >>> | compliment_desc | varchar(255) | NO | | | | >>> | status_desc | varchar(255) | NO | | | | >>> | parameter | varchar(255) | NO | | | | >>> | cause | varchar(255) | NO | UNI | | | >>> | disabled | tinyint(1) | NO | | 0 | | >>> +-----------------+--------------+------+-----+---------+----------------+ >>> >>> It seems that Erlang ODBC driver does not support the mysql type >>> varchar? How can I use the database without touching the db schema? >>> >>> >>> Some details about the system env: >>> >>> $ uname -a >>> Linux 2.6.36-gentoo-r8 #4 SMP Thu Apr 7 20:13:18 CST 2011 x86_64 >>> Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz GenuineIntel GNU/Linux >>> >>> $ erl >>> Erlang R13B04 (erts-5.7.5) [source] [64-bit] [smp:2:2] [rq:2] >>> [async-threads:0] [kernel-poll:false] >>> >>> $ emerge -vp erlang >>> dev-lang/erlang-13.2.4 USE="doc kpoll odbc smp ssl -emacs -hipe -java >>> -sctp -tk -wxwidgets" >>> >>> eshell> code:which(odbc). >>> "/usr/lib64/erlang/lib/odbc-2.10.7/ebin/odbc.beam" >>> >>> $ mysql -V >>> mysql Ver 14.14 Distrib 5.1.51, for pc-linux-gnu (x86_64) using readline 5.1 >>> >>> Server version: 5.1.51-log Gentoo Linux mysql-5.1.51 >>> >>> $ emerge -vp myodbc >>> dev-db/myodbc-5.1.6 USE="-debug -doc -qt4 -static" >>> >>> >>> Any help will be greatly appreciated. Thanks in advance. >>> Sorry for my poor English, I'm not a native... >>> >>> Best, >>> >>> -- >>> Hanfei >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> > > From carlo.bertoldi@REDACTED Mon May 2 11:41:56 2011 From: carlo.bertoldi@REDACTED (Carlo Bertoldi) Date: Mon, 02 May 2011 11:41:56 +0200 Subject: [erlang-questions] Dialyzer In-Reply-To: <4DBE782D.80300@cs.ntua.gr> References: <4DBE744D.5060909@ubiquity.it> <4DBE782D.80300@cs.ntua.gr> Message-ID: <4DBE7C64.4050701@ubiquity.it> On 02/05/2011 11:23, Kostis Sagonas wrote: > Carlo Bertoldi wrote: >> Hello list, >> this is a bad monday, and I'm stuck with this warning from dialyzer: >> >> The specification for change_interval/2 states that the function >> might also return [any()] but the inferred return is none() >> >> The code: >> -spec(change_interval(integer(), [term()]) -> [term()]). >> >> change_interval(NewInterval, Config) -> >> NewPause = {pause, NewInterval}, >> NewConfig = lists:keyreplace(pause, 1, Config, NewPause), >> write_config(NewPause), >> NewConfig. >> I apologize for the incompleteness, here goes the module -module(test). -export([test_write_config/0]). -define(PAUSE_FILE, "test.conf"). -spec(change_interval(integer(), [term()]) -> [term()]). change_interval(NewInterval, Config) -> NewPause = {pause, NewInterval}, NewConfig = lists:keyreplace(pause, 1, Config, NewPause), write_config(NewPause), NewConfig. -spec(write_config(tuple(pause, integer())) -> ok | error). write_config(Pause) -> File = ?PAUSE_FILE, case file:open(File, write) of {ok , F} -> io:format(F, "~w.", [Pause]), file:close(F), ok; {error, Reason} -> io:format("Error opening file ~p: ~p~n", [File, Reason]), error end. test_write_config() -> Pause = {pause, 6767576}, write_config(Pause), {ok, Config} = file:consult(?PAUSE_FILE), Config. ?PAUSE_FILE's content: {pause,2000}. Dialyzer version is 2.3.0 Carlo From kostis@REDACTED Mon May 2 11:55:00 2011 From: kostis@REDACTED (Kostis Sagonas) Date: Mon, 02 May 2011 12:55:00 +0300 Subject: [erlang-questions] Dialyzer In-Reply-To: <4DBE7C64.4050701@ubiquity.it> References: <4DBE744D.5060909@ubiquity.it> <4DBE782D.80300@cs.ntua.gr> <4DBE7C64.4050701@ubiquity.it> Message-ID: <4DBE7F74.6090601@cs.ntua.gr> Carlo Bertoldi wrote: > On 02/05/2011 11:23, Kostis Sagonas wrote: >> Carlo Bertoldi wrote: >>> Hello list, >>> this is a bad monday, and I'm stuck with this warning from dialyzer: >>> >>> The specification for change_interval/2 states that the function >>> might also return [any()] but the inferred return is none() >>> >>> The code: >>> -spec(change_interval(integer(), [term()]) -> [term()]). >>> >>> change_interval(NewInterval, Config) -> >>> NewPause = {pause, NewInterval}, >>> NewConfig = lists:keyreplace(pause, 1, Config, NewPause), >>> write_config(NewPause), >>> NewConfig. >>> > I apologize for the incompleteness, here goes the module Well, probably it's a bad Monday alright for you. Wondering what exactly it is you did during the weekend... ;) Anyway, didn't you happen to notice that dialyzer generates an awful lot of other warnings for this module? Among them, a warning that basically tells you that the proper way to use file:open/2 is with a list of options in the second argument, i.e. file:open(File, [write]), instead of what you've written below? Please fix this. As to the warning you are getting, can't you see that the function change_interval/2 is nowhere used in this file? Even erlc will tell you that. Kostis > -module(test). > -export([test_write_config/0]). > > -define(PAUSE_FILE, "test.conf"). > > -spec(change_interval(integer(), [term()]) -> [term()]). > > change_interval(NewInterval, Config) -> > NewPause = {pause, NewInterval}, > NewConfig = lists:keyreplace(pause, 1, Config, NewPause), > write_config(NewPause), > NewConfig. > > -spec(write_config(tuple(pause, integer())) -> ok | error). > write_config(Pause) -> > File = ?PAUSE_FILE, > case file:open(File, write) of > {ok , F} -> > io:format(F, "~w.", [Pause]), > file:close(F), > ok; > {error, Reason} -> > io:format("Error opening file ~p: ~p~n", [File, Reason]), > error > end. > > test_write_config() -> > Pause = {pause, 6767576}, > write_config(Pause), > {ok, Config} = file:consult(?PAUSE_FILE), > Config. From raimo+erlang-questions@REDACTED Mon May 2 11:58:24 2011 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Mon, 2 May 2011 11:58:24 +0200 Subject: [erlang-questions] byte() vs. char() use in documentation In-Reply-To: <372726991.139721304328918708.JavaMail.root@zimbra> References: <20110502091415.GA6512@erix.ericsson.se> <372726991.139721304328918708.JavaMail.root@zimbra> Message-ID: <20110502095824.GA9576@erix.ericsson.se> On Mon, May 02, 2011 at 09:35:18AM +0000, Robert Virding wrote: > > ----- "Raimo Niskanen" wrote: > > > On Mon, May 02, 2011 at 12:01:49AM +0100, James Churchman wrote: > > > more of a question than an actual answer, but in erlang can erlang > > strings ( therefore io-lists) be utf-16? > > > > A string is a list of unicode code points. > > > > An IO-list is a list of binaries or bytes. > > > > > > > > I assume that binaries are obviously only ever utf8 representation, > > but a list of ints can obviously exceed number above 255.. > > > > You can choose your binary representation. See erlang man page > > unicode(3). > > > > > > > > so maybe (??) the answer is > > > > > > a) iolist CAN be a char() (.. this is surely especially true if the > > data is only being messages threw erlang from other systems) > > > > No. byte(). > > As a string is a list of unicode code points and an iolist can contain a string then its type must also be char(). No. As it stands now a string is a list of unicode code points and can not be contained in an iolist. This became messy when char() was re-defined from latin-1 character to unicode character. That affected string() that affected iolist() and the latter was incorrect. We must clean up the mess. Either by completing the notion of char() being unicode and hence rewriting iolist() to contain byte() and binary(), or by reverting to char() being latin-1 char and using unicode:char() and unicode:string() where that is correct... > > Robert -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From carlo.bertoldi@REDACTED Mon May 2 12:11:30 2011 From: carlo.bertoldi@REDACTED (Carlo Bertoldi) Date: Mon, 02 May 2011 12:11:30 +0200 Subject: [erlang-questions] Dialyzer In-Reply-To: <4DBE7F74.6090601@cs.ntua.gr> References: <4DBE744D.5060909@ubiquity.it> <4DBE782D.80300@cs.ntua.gr> <4DBE7C64.4050701@ubiquity.it> <4DBE7F74.6090601@cs.ntua.gr> Message-ID: <4DBE8352.4000809@ubiquity.it> On 02/05/2011 11:55, Kostis Sagonas wrote: > Carlo Bertoldi wrote: >> On 02/05/2011 11:23, Kostis Sagonas wrote: >>> Carlo Bertoldi wrote: >>>> Hello list, >>>> this is a bad monday, and I'm stuck with this warning from dialyzer: >>>> >>>> The specification for change_interval/2 states that the function >>>> might also return [any()] but the inferred return is none() >>>> >>>> The code: >>>> -spec(change_interval(integer(), [term()]) -> [term()]). >>>> >>>> change_interval(NewInterval, Config) -> >>>> NewPause = {pause, NewInterval}, >>>> NewConfig = lists:keyreplace(pause, 1, Config, NewPause), >>>> write_config(NewPause), >>>> NewConfig. >>>> >> I apologize for the incompleteness, here goes the module > > Well, probably it's a bad Monday alright for you. Wondering what > exactly it is you did during the weekend... ;) You don't wanna know ;) > > Anyway, didn't you happen to notice that dialyzer generates an awful > lot of other warnings for this module? Actually yes, but I thought about resolving the first issue of the list before. Of course I was awfully wrong, after fixing the call to file:open, all the other warnings disappeared in a puff of logic. This is a silly error indeed, but I wonder, how come that write_config was working anyway? I tested that before the weekend ;) > Among them, a warning that basically tells you that the proper way to > use file:open/2 is with a list of options in the second argument, i.e. > file:open(File, [write]), instead of what you've written below? > Please fix this. > > As to the warning you are getting, can't you see that the function > change_interval/2 is nowhere used in this file? Even erlc will tell > you that. Sorry again, I didn't paste every lines of the actual module, and I've read the mail a couple of times. Guess I do need a triple coffee. Carlo From kostis@REDACTED Mon May 2 12:13:08 2011 From: kostis@REDACTED (Kostis Sagonas) Date: Mon, 02 May 2011 13:13:08 +0300 Subject: [erlang-questions] byte() vs. char() use in documentation In-Reply-To: <20110502095824.GA9576@erix.ericsson.se> References: <20110502091415.GA6512@erix.ericsson.se> <372726991.139721304328918708.JavaMail.root@zimbra> <20110502095824.GA9576@erix.ericsson.se> Message-ID: <4DBE83B4.50501@cs.ntua.gr> Raimo Niskanen wrote: > > This became messy when char() was re-defined from latin-1 character > to unicode character. That affected string() that affected iolist() > and the latter was incorrect. > > We must clean up the mess. Right. The sooner it happens the better it is. > ... Either by completing the notion of char() > being unicode and hence rewriting iolist() to contain byte() and binary(), > or by reverting to char() being latin-1 char and using unicode:char() > and unicode:string() where that is correct... Please, by all means do the former. The latter will only cause havoc everywhere. For starters, I do not see any need in having two different basic types (byte() and char()) denoting (pretty much) the same thing. The only thing this does is cause unnecessary confusion to newcomers (and apparently to some old-timers too). Second, if you choose the latter you will eventually have to change lots of type inference code, because I promise you I will not do this, and believe me you don't want to go there... (The Vietnam jungle is probably a friendlier place ;) ) Cheers, Kostis From attila.r.nohl@REDACTED Mon May 2 12:53:00 2011 From: attila.r.nohl@REDACTED (Attila Rajmund Nohl) Date: Mon, 2 May 2011 12:53:00 +0200 Subject: [erlang-questions] Dialyzer In-Reply-To: <4DBE8352.4000809@ubiquity.it> References: <4DBE744D.5060909@ubiquity.it> <4DBE782D.80300@cs.ntua.gr> <4DBE7C64.4050701@ubiquity.it> <4DBE7F74.6090601@cs.ntua.gr> <4DBE8352.4000809@ubiquity.it> Message-ID: 2011/5/2, Carlo Bertoldi : [...] > This is a silly error indeed, but I wonder, how come that write_config > was working anyway? > I tested that before the weekend ;) Backward compatibility, see the documentation :-) From mrtndimitrov@REDACTED Mon May 2 14:32:26 2011 From: mrtndimitrov@REDACTED (Martin Dimitrov) Date: Mon, 2 May 2011 15:32:26 +0300 (EEST) Subject: [erlang-questions] supervisor:start_child Message-ID: <1254050495.821435.1304339546692.JavaMail.apache@nm2.abv.bg> Hi, I am developing a server that needs to spawn (under supervision) multiple child processes. Since these processes will be of different gen_server type, I cannot use simple_one_of_one restart strategy. These servers are anonymous, I refer to them by their Pids. The problem I get is when I try to run 2 or more servers from the same type with the same id inside the child specification. I receive already_started error. By making the ids different, everything works fine. My question is why the id inside the child specification needs to be different for every process (even if it is of the same type)? What is the best practice to deal with this? Can the creation of dynamic ids be avoided? Thanks, Regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From ingela@REDACTED Mon May 2 15:41:24 2011 From: ingela@REDACTED (Ingela Andin) Date: Mon, 2 May 2011 15:41:24 +0200 Subject: [erlang-questions] httpc manager crashes In-Reply-To: References: Message-ID: Hi! 2011/4/29 Arun Suresh : > Helo Ingela > I am Suma's colleague. Let me try to give more context to the issue we are > facing.. > * Our app make a LOT (in the range of around 300) of http requests > concurrently. > * There are two types of requests > ?? 1) POST requests : These require us to go thru a proxy. These can > themselves hit about 150 ?- 200concurrent requests. > ?? 2) GET requests : ?Standard http requests. > As far as the GET requests are concerned, we start some 300 profiles and > randomly pick one for use. > Since we have to send our POSTs via a proxy, at app initialialization time, > we start 1 httpc profile. We see a lot of httpc_manager crashes pertaining > to this particular profile. I understand that the httpc_manager is supposed > to be a pretty light weight process.. not requiring any synchronization with > the manager.. Is there a chance that the httpc_manager can crash ? Also, I > was wondering, is the Data to be posted also copied to the httpc_managers > message queue before its again copied to the handlers message queue before > actually sending ? Crashes are always a possibility and the httpc_manager will be restarted if it crashes. But normally it should not crash. We think the behavior you have seen is a bug, and we are working on fixing it. There are also some other known problems such as the copying issue of the request information that is unnecessary. We are are working on solving this too but it may require a little more work to make a good solution and we are as always struggling with priorities of all things we need to do, but it is in the plans. Regards Ingela Erlang OTP team - Ericsson AB From t.greenwoodgeer@REDACTED Mon May 2 16:58:05 2011 From: t.greenwoodgeer@REDACTED (Todd) Date: Mon, 02 May 2011 07:58:05 -0700 Subject: [erlang-questions] ets table disappears after bad query In-Reply-To: References: <4DBE4731.4030609@gmail.com> <4DBE6CA3.3000109@ubiquity.it> Message-ID: <4DBEC67D.20405@gmail.com> Thanks for all the responses. Funny enough, I remember reading about this in the books/docs somewhere, but it's altogether another thing to encounter this in the wild. On 5/2/11 1:51 AM, Masklinn wrote: > On 2 mai 2011, at 10:34, Carlo Bertoldi wrote: >> On 02/05/2011 07:54, Todd wrote: >>> I have an ets query that is broken. The funny thing is that after the query fails, the ets table disappears... >>> >>> 6. Is this expected behaviour? What would I have to do to prevent losing my ets table? >>> >> Yes. To avoid this you should create the table in a process, start it without linking to it, and then run you query. >> Then the crash due to the wrong query shouldn't bring down you ets. >> > An other alternative would be to declare an other process as the table's owner and the shell process as inheritor. That way, the owner process dies on a bad query, the shell gets the intact table back and can just create a new sacrificial process to own the table for the next query. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From qqshfox@REDACTED Mon May 2 17:18:21 2011 From: qqshfox@REDACTED (Hanfei Shen) Date: Mon, 2 May 2011 23:18:21 +0800 Subject: [erlang-questions] Erlang and MySQL: ODBC, Column type not supported In-Reply-To: <4DBE7B49.1080505@erix.ericsson.se> References: <4DBE7B49.1080505@erix.ericsson.se> Message-ID: Hi, I had changed the type from SQLINTEGER to SQLSMALLINT, but the problem is still there... (gdb) i func encode_data_type File odbcserver.c: static void encode_data_type(SQLSMALLINT, SQLINTEGER, SQLSMALLINT, db_state *); Breakpoint 1, encode_data_type (sql_type=-9, size=255, decimal_digits=0, state=0x7fffa5380210) at odbcserver.c:1396 1396 switch(sql_type) { Do you need any details? 2011/5/2 Ingela Anderton Andin : > Hi! > > Hanfei Shen wrote: >> >> Hi Ingela, >> >> Did you mean the value of variable "sql_type"? >> >> > > Yes. > >> I tried to inspect it through gdb, setting a break on func >> encode_data_type. And then I got: >> >> Breakpoint 1, encode_data_type (sql_type=-9, size=255, >> decimal_digits=0, state=0x7fffc657ec40) at odbcserver.c:1396 >> 1396 ? ? ? ?switch(sql_type) { >> >> > > Well that is defenetly not a good value. Looking at the code just now > I noticed that > > encode_data_type defines sql_type as "SQLINTEGER sql_type" and it > ought to be "SQLSMALLINT sql_type". If you change that does it fix your > problem? > > Regards Ingela Erlang/OTP team - Ericsson AB > > > >> 2011/5/2 Ingela Andin : >> >>> >>> Hi! >>> >>> The erlang odbc application supports {sql-varchars, ?N} where N = 255 >>> in your case. The return values >>> you get suggest that the odbc-driver you have returns an unexpected >>> column type. >>> >>> In the erlang odbc port program there is a switch that handles type >>> when describing a coloumn that if we take out >>> the handling code looks like this. >>> >>> switch(sql_type) { >>> ? case SQL_CHAR: >>> ? case SQL_VARCHAR: >>> ? case SQL_WCHAR: >>> ? case SQL_WVARCHAR: >>> ? case SQL_NUMERIC: >>> ? case SQL_DECIMAL: >>> ? case SQL_INTEGER: >>> ? case SQL_TINYINT: >>> ? case SQL_SMALLINT: >>> ? case SQL_REAL: >>> ? case SQL_FLOAT: >>> ? case SQL_DOUBLE: >>> ? case SQL_BIT: >>> ? case SQL_TYPE_DATE: >>> ? case SQL_TYPE_TIME: >>> ? case SQL_TYPE_TIMESTAMP: >>> ? case SQL_BIGINT: >>> ? case SQL_BINARY: >>> ? case SQL_LONGVARCHAR: >>> ? case SQL_VARBINARY: >>> ? case SQL_LONGVARBINARY: >>> ? case SQL_INTERVAL_MONTH: >>> ? case SQL_INTERVAL_YEAR: >>> ? case SQL_INTERVAL_DAY: >>> ? case SQL_INTERVAL_MINUTE: >>> ? case SQL_INTERVAL_HOUR_TO_SECOND: >>> ? case SQL_INTERVAL_MINUTE_TO_SECOND: >>> ? case SQL_UNKNOWN_TYPE: >>> ? default: /* Will probably never happen */ >>> ? ? ? ei_x_encode_atom(&dynamic_buffer(state), "ODBC_UNSUPPORTED_TYPE"); >>> ? ? ? break; >>> ? } >>> >>> >>> And you end up in the default clause which is very unexpected and the >>> root to your problem. ?If ?you can figur out >>> what your driver returns for the ODBC C-API function SQLDescribeCol we >>> could know if the driver is at fault or if the odbc-port program is. >>> >>> Regards ?Ingela Erlang/OTP team - Ericsson AB >>> >>> 2011/5/1 Hanfei Shen : >>> >>>> >>>> Dear all, >>>> >>>> I'm a newbie programming in erlang. When I used ODBC to connect to a >>>> MySQL database through Connector/ODBC (MyODBC), I got some error when >>>> calling odbc:sql_query(Conn, "SELECT * FROM action"): >>>> >>>> {error,"Column type not supported"} >>>> >>>> Then I call odbc:describe_table(Conn, "action"), it returned: >>>> >>>> {ok,[{"id",sql_integer}, >>>> ? ? {"code",'ODBC_UNSUPPORTED_TYPE'}, >>>> ? ? {"compliment_desc",'ODBC_UNSUPPORTED_TYPE'}, >>>> ? ? {"status_desc",'ODBC_UNSUPPORTED_TYPE'}, >>>> ? ? {"parameter",'ODBC_UNSUPPORTED_TYPE'}, >>>> ? ? {"cause",'ODBC_UNSUPPORTED_TYPE'}, >>>> ? ? {"disabled",sql_tinyint}]} >>>> >>>> And desc the table in mysql client: >>>> mysql> desc action; >>>> >>>> +-----------------+--------------+------+-----+---------+----------------+ >>>> | Field ? ? ? ? ? | Type ? ? ? ? | Null | Key | Default | Extra >>>> ?| >>>> >>>> +-----------------+--------------+------+-----+---------+----------------+ >>>> | id ? ? ? ? ? ? ?| int(11) ? ? ?| NO ? | PRI | NULL ? ?| auto_increment >>>> | >>>> | code ? ? ? ? ? ?| varchar(255) | NO ? | ? ? | NULL ? ?| >>>> ?| >>>> | compliment_desc | varchar(255) | NO ? | ? ? | ? ? ? ? | >>>> ?| >>>> | status_desc ? ? | varchar(255) | NO ? | ? ? | ? ? ? ? | >>>> ?| >>>> | parameter ? ? ? | varchar(255) | NO ? | ? ? | ? ? ? ? | >>>> ?| >>>> | cause ? ? ? ? ? | varchar(255) | NO ? | UNI | ? ? ? ? | >>>> ?| >>>> | disabled ? ? ? ?| tinyint(1) ? | NO ? | ? ? | 0 ? ? ? | >>>> ?| >>>> >>>> +-----------------+--------------+------+-----+---------+----------------+ >>>> >>>> It seems that Erlang ODBC driver does not support the mysql type >>>> varchar? How can I use the database without touching the db schema? >>>> >>>> >>>> Some details about the system env: >>>> >>>> $ uname -a >>>> Linux 2.6.36-gentoo-r8 #4 SMP Thu Apr 7 20:13:18 CST 2011 x86_64 >>>> Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz GenuineIntel GNU/Linux >>>> >>>> $ erl >>>> Erlang R13B04 (erts-5.7.5) [source] [64-bit] [smp:2:2] [rq:2] >>>> [async-threads:0] [kernel-poll:false] >>>> >>>> $ emerge -vp erlang >>>> dev-lang/erlang-13.2.4 ?USE="doc kpoll odbc smp ssl -emacs -hipe -java >>>> -sctp -tk -wxwidgets" >>>> >>>> eshell> code:which(odbc). >>>> "/usr/lib64/erlang/lib/odbc-2.10.7/ebin/odbc.beam" >>>> >>>> $ mysql -V >>>> mysql ?Ver 14.14 Distrib 5.1.51, for pc-linux-gnu (x86_64) using >>>> readline 5.1 >>>> >>>> Server version: 5.1.51-log Gentoo Linux mysql-5.1.51 >>>> >>>> $ emerge -vp myodbc >>>> dev-db/myodbc-5.1.6 ?USE="-debug -doc -qt4 -static" >>>> >>>> >>>> Any help will be greatly appreciated. ?Thanks in advance. >>>> Sorry for my poor English, I'm not a native... >>>> >>>> Best, >>>> >>>> -- >>>> Hanfei >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>>> >> >> > > From gregory.haskins@REDACTED Mon May 2 17:29:38 2011 From: gregory.haskins@REDACTED (Gregory Haskins) Date: Mon, 02 May 2011 11:29:38 -0400 Subject: [erlang-questions] Best practices for distributing an application over erlang? In-Reply-To: <4D7A9E61.6020204@gmail.com> References: <38126.1297968825@snookles.snookles.com> <4D7A9E61.6020204@gmail.com> Message-ID: <4DBECDE2.7020305@gmail.com> On 3/11/11 5:12 PM, Gregory Haskins wrote: > Thanks for the detailed reply, Scott. I was afraid of your answer, but > I started putting together a prototype to address this apparent > shortcoming. I call it "EDist", short for erlang-distribution. If > anyone is curious, I have the code up on github: > > https://github.com/ghaskins/edist > > Ill update the wiki with better notes on what it does today and what I > want it to do in the future. Update: Well, I still do not have a good wiki, but I at least posted a screencast over the weekend: http://vimeo.com/23063557 Feedback on the project (or the screencast) welcome. Kind Regards, -Greg PS: Special thanks to Ulf for all the fantastic support getting gproc working for my application. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 267 bytes Desc: OpenPGP digital signature URL: From ingela@REDACTED Mon May 2 18:08:10 2011 From: ingela@REDACTED (Ingela Andin) Date: Mon, 2 May 2011 18:08:10 +0200 Subject: [erlang-questions] Erlang and MySQL: ODBC, Column type not supported In-Reply-To: References: <4DBE7B49.1080505@erix.ericsson.se> Message-ID: Hi! Well the best thing would be if you can provide me with a way to reproduce it. Do you have the possibility to try another odbc-driver with your database? Regards Ingela Erlang/OTP team - Ericsson AB 2011/5/2 Hanfei Shen : > Hi, > > I had changed the type from SQLINTEGER to SQLSMALLINT, but the problem > is still there... > > (gdb) i func encode_data_type > File odbcserver.c: > static void encode_data_type(SQLSMALLINT, SQLINTEGER, SQLSMALLINT, db_state *); > > Breakpoint 1, encode_data_type (sql_type=-9, size=255, > decimal_digits=0, state=0x7fffa5380210) at odbcserver.c:1396 > 1396 ? ? ? ?switch(sql_type) { > > Do you need any details? > > 2011/5/2 Ingela Anderton Andin : >> Hi! >> >> Hanfei Shen wrote: >>> >>> Hi Ingela, >>> >>> Did you mean the value of variable "sql_type"? >>> >>> >> >> Yes. >> >>> I tried to inspect it through gdb, setting a break on func >>> encode_data_type. And then I got: >>> >>> Breakpoint 1, encode_data_type (sql_type=-9, size=255, >>> decimal_digits=0, state=0x7fffc657ec40) at odbcserver.c:1396 >>> 1396 ? ? ? ?switch(sql_type) { >>> >>> >> >> Well that is defenetly not a good value. Looking at the code just now >> I noticed that >> >> encode_data_type defines sql_type as "SQLINTEGER sql_type" and it >> ought to be "SQLSMALLINT sql_type". If you change that does it fix your >> problem? >> >> Regards Ingela Erlang/OTP team - Ericsson AB >> >> >> >>> 2011/5/2 Ingela Andin : >>> >>>> >>>> Hi! >>>> >>>> The erlang odbc application supports {sql-varchars, ?N} where N = 255 >>>> in your case. The return values >>>> you get suggest that the odbc-driver you have returns an unexpected >>>> column type. >>>> >>>> In the erlang odbc port program there is a switch that handles type >>>> when describing a coloumn that if we take out >>>> the handling code looks like this. >>>> >>>> switch(sql_type) { >>>> ? case SQL_CHAR: >>>> ? case SQL_VARCHAR: >>>> ? case SQL_WCHAR: >>>> ? case SQL_WVARCHAR: >>>> ? case SQL_NUMERIC: >>>> ? case SQL_DECIMAL: >>>> ? case SQL_INTEGER: >>>> ? case SQL_TINYINT: >>>> ? case SQL_SMALLINT: >>>> ? case SQL_REAL: >>>> ? case SQL_FLOAT: >>>> ? case SQL_DOUBLE: >>>> ? case SQL_BIT: >>>> ? case SQL_TYPE_DATE: >>>> ? case SQL_TYPE_TIME: >>>> ? case SQL_TYPE_TIMESTAMP: >>>> ? case SQL_BIGINT: >>>> ? case SQL_BINARY: >>>> ? case SQL_LONGVARCHAR: >>>> ? case SQL_VARBINARY: >>>> ? case SQL_LONGVARBINARY: >>>> ? case SQL_INTERVAL_MONTH: >>>> ? case SQL_INTERVAL_YEAR: >>>> ? case SQL_INTERVAL_DAY: >>>> ? case SQL_INTERVAL_MINUTE: >>>> ? case SQL_INTERVAL_HOUR_TO_SECOND: >>>> ? case SQL_INTERVAL_MINUTE_TO_SECOND: >>>> ? case SQL_UNKNOWN_TYPE: >>>> ? default: /* Will probably never happen */ >>>> ? ? ? ei_x_encode_atom(&dynamic_buffer(state), "ODBC_UNSUPPORTED_TYPE"); >>>> ? ? ? break; >>>> ? } >>>> >>>> >>>> And you end up in the default clause which is very unexpected and the >>>> root to your problem. ?If ?you can figur out >>>> what your driver returns for the ODBC C-API function SQLDescribeCol we >>>> could know if the driver is at fault or if the odbc-port program is. >>>> >>>> Regards ?Ingela Erlang/OTP team - Ericsson AB >>>> >>>> 2011/5/1 Hanfei Shen : >>>> >>>>> >>>>> Dear all, >>>>> >>>>> I'm a newbie programming in erlang. When I used ODBC to connect to a >>>>> MySQL database through Connector/ODBC (MyODBC), I got some error when >>>>> calling odbc:sql_query(Conn, "SELECT * FROM action"): >>>>> >>>>> {error,"Column type not supported"} >>>>> >>>>> Then I call odbc:describe_table(Conn, "action"), it returned: >>>>> >>>>> {ok,[{"id",sql_integer}, >>>>> ? ? {"code",'ODBC_UNSUPPORTED_TYPE'}, >>>>> ? ? {"compliment_desc",'ODBC_UNSUPPORTED_TYPE'}, >>>>> ? ? {"status_desc",'ODBC_UNSUPPORTED_TYPE'}, >>>>> ? ? {"parameter",'ODBC_UNSUPPORTED_TYPE'}, >>>>> ? ? {"cause",'ODBC_UNSUPPORTED_TYPE'}, >>>>> ? ? {"disabled",sql_tinyint}]} >>>>> >>>>> And desc the table in mysql client: >>>>> mysql> desc action; >>>>> >>>>> +-----------------+--------------+------+-----+---------+----------------+ >>>>> | Field ? ? ? ? ? | Type ? ? ? ? | Null | Key | Default | Extra >>>>> ?| >>>>> >>>>> +-----------------+--------------+------+-----+---------+----------------+ >>>>> | id ? ? ? ? ? ? ?| int(11) ? ? ?| NO ? | PRI | NULL ? ?| auto_increment >>>>> | >>>>> | code ? ? ? ? ? ?| varchar(255) | NO ? | ? ? | NULL ? ?| >>>>> ?| >>>>> | compliment_desc | varchar(255) | NO ? | ? ? | ? ? ? ? | >>>>> ?| >>>>> | status_desc ? ? | varchar(255) | NO ? | ? ? | ? ? ? ? | >>>>> ?| >>>>> | parameter ? ? ? | varchar(255) | NO ? | ? ? | ? ? ? ? | >>>>> ?| >>>>> | cause ? ? ? ? ? | varchar(255) | NO ? | UNI | ? ? ? ? | >>>>> ?| >>>>> | disabled ? ? ? ?| tinyint(1) ? | NO ? | ? ? | 0 ? ? ? | >>>>> ?| >>>>> >>>>> +-----------------+--------------+------+-----+---------+----------------+ >>>>> >>>>> It seems that Erlang ODBC driver does not support the mysql type >>>>> varchar? How can I use the database without touching the db schema? >>>>> >>>>> >>>>> Some details about the system env: >>>>> >>>>> $ uname -a >>>>> Linux 2.6.36-gentoo-r8 #4 SMP Thu Apr 7 20:13:18 CST 2011 x86_64 >>>>> Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz GenuineIntel GNU/Linux >>>>> >>>>> $ erl >>>>> Erlang R13B04 (erts-5.7.5) [source] [64-bit] [smp:2:2] [rq:2] >>>>> [async-threads:0] [kernel-poll:false] >>>>> >>>>> $ emerge -vp erlang >>>>> dev-lang/erlang-13.2.4 ?USE="doc kpoll odbc smp ssl -emacs -hipe -java >>>>> -sctp -tk -wxwidgets" >>>>> >>>>> eshell> code:which(odbc). >>>>> "/usr/lib64/erlang/lib/odbc-2.10.7/ebin/odbc.beam" >>>>> >>>>> $ mysql -V >>>>> mysql ?Ver 14.14 Distrib 5.1.51, for pc-linux-gnu (x86_64) using >>>>> readline 5.1 >>>>> >>>>> Server version: 5.1.51-log Gentoo Linux mysql-5.1.51 >>>>> >>>>> $ emerge -vp myodbc >>>>> dev-db/myodbc-5.1.6 ?USE="-debug -doc -qt4 -static" >>>>> >>>>> >>>>> Any help will be greatly appreciated. ?Thanks in advance. >>>>> Sorry for my poor English, I'm not a native... >>>>> >>>>> Best, >>>>> >>>>> -- >>>>> Hanfei >>>>> _______________________________________________ >>>>> erlang-questions mailing list >>>>> erlang-questions@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>>> >>>>> >>> >>> >> >> > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From mihai@REDACTED Mon May 2 18:13:16 2011 From: mihai@REDACTED (Mihai Balea) Date: Mon, 2 May 2011 12:13:16 -0400 Subject: [erlang-questions] supervisor:start_child In-Reply-To: <1254050495.821435.1304339546692.JavaMail.apache@nm2.abv.bg> References: <1254050495.821435.1304339546692.JavaMail.apache@nm2.abv.bg> Message-ID: On May 2, 2011, at 8:32 AM, Martin Dimitrov wrote: > Hi, > > I am developing a server that needs to spawn (under supervision) multiple child processes. Since these processes will be of different gen_server type, I cannot use simple_one_of_one restart strategy. These servers are anonymous, I refer to them by their Pids. I think you might be able to use a simple one for one supervisor to start different types of gen_servers. You would need to create an interface module to be used in the child spec, a module that would in turn call your various other gen_servers according to some parameters. I've never done this, but I don't see why it wouldn't work. > > The problem I get is when I try to run 2 or more servers from the same type with the same id inside the child specification. I receive already_started error. By making the ids different, everything works fine. > > My question is why the id inside the child specification needs to be different for every process (even if it is of the same type)? What is the best practice to deal with this? Can the creation of dynamic ids be avoided? A normal (i.e. not simple_on_for_one) supervisor allows you to stop, restart and delete children processes, so it needs a way to identify them. Hence the id. Mihai From qqshfox@REDACTED Mon May 2 18:15:35 2011 From: qqshfox@REDACTED (Hanfei Shen) Date: Tue, 3 May 2011 00:15:35 +0800 Subject: [erlang-questions] Erlang and MySQL: ODBC, Column type not supported In-Reply-To: References: <4DBE7B49.1080505@erix.ericsson.se> Message-ID: Hi, I've tried https://github.com/dizzyd/erlang-mysql-driver, it works. I'm installing unixodbc... Wait a minute. Thnx... 2011/5/3 Ingela Andin : > Hi! > > Well the best thing would be if you can provide me with a way to reproduce it. > Do you have the possibility to try another odbc-driver with your database? > > Regards Ingela Erlang/OTP team - Ericsson AB > > > 2011/5/2 Hanfei Shen : >> Hi, >> >> I had changed the type from SQLINTEGER to SQLSMALLINT, but the problem >> is still there... >> >> (gdb) i func encode_data_type >> File odbcserver.c: >> static void encode_data_type(SQLSMALLINT, SQLINTEGER, SQLSMALLINT, db_state *); >> >> Breakpoint 1, encode_data_type (sql_type=-9, size=255, >> decimal_digits=0, state=0x7fffa5380210) at odbcserver.c:1396 >> 1396 ? ? ? ?switch(sql_type) { >> >> Do you need any details? >> >> 2011/5/2 Ingela Anderton Andin : >>> Hi! >>> >>> Hanfei Shen wrote: >>>> >>>> Hi Ingela, >>>> >>>> Did you mean the value of variable "sql_type"? >>>> >>>> >>> >>> Yes. >>> >>>> I tried to inspect it through gdb, setting a break on func >>>> encode_data_type. And then I got: >>>> >>>> Breakpoint 1, encode_data_type (sql_type=-9, size=255, >>>> decimal_digits=0, state=0x7fffc657ec40) at odbcserver.c:1396 >>>> 1396 ? ? ? ?switch(sql_type) { >>>> >>>> >>> >>> Well that is defenetly not a good value. Looking at the code just now >>> I noticed that >>> >>> encode_data_type defines sql_type as "SQLINTEGER sql_type" and it >>> ought to be "SQLSMALLINT sql_type". If you change that does it fix your >>> problem? >>> >>> Regards Ingela Erlang/OTP team - Ericsson AB >>> >>> >>> >>>> 2011/5/2 Ingela Andin : >>>> >>>>> >>>>> Hi! >>>>> >>>>> The erlang odbc application supports {sql-varchars, ?N} where N = 255 >>>>> in your case. The return values >>>>> you get suggest that the odbc-driver you have returns an unexpected >>>>> column type. >>>>> >>>>> In the erlang odbc port program there is a switch that handles type >>>>> when describing a coloumn that if we take out >>>>> the handling code looks like this. >>>>> >>>>> switch(sql_type) { >>>>> ? case SQL_CHAR: >>>>> ? case SQL_VARCHAR: >>>>> ? case SQL_WCHAR: >>>>> ? case SQL_WVARCHAR: >>>>> ? case SQL_NUMERIC: >>>>> ? case SQL_DECIMAL: >>>>> ? case SQL_INTEGER: >>>>> ? case SQL_TINYINT: >>>>> ? case SQL_SMALLINT: >>>>> ? case SQL_REAL: >>>>> ? case SQL_FLOAT: >>>>> ? case SQL_DOUBLE: >>>>> ? case SQL_BIT: >>>>> ? case SQL_TYPE_DATE: >>>>> ? case SQL_TYPE_TIME: >>>>> ? case SQL_TYPE_TIMESTAMP: >>>>> ? case SQL_BIGINT: >>>>> ? case SQL_BINARY: >>>>> ? case SQL_LONGVARCHAR: >>>>> ? case SQL_VARBINARY: >>>>> ? case SQL_LONGVARBINARY: >>>>> ? case SQL_INTERVAL_MONTH: >>>>> ? case SQL_INTERVAL_YEAR: >>>>> ? case SQL_INTERVAL_DAY: >>>>> ? case SQL_INTERVAL_MINUTE: >>>>> ? case SQL_INTERVAL_HOUR_TO_SECOND: >>>>> ? case SQL_INTERVAL_MINUTE_TO_SECOND: >>>>> ? case SQL_UNKNOWN_TYPE: >>>>> ? default: /* Will probably never happen */ >>>>> ? ? ? ei_x_encode_atom(&dynamic_buffer(state), "ODBC_UNSUPPORTED_TYPE"); >>>>> ? ? ? break; >>>>> ? } >>>>> >>>>> >>>>> And you end up in the default clause which is very unexpected and the >>>>> root to your problem. ?If ?you can figur out >>>>> what your driver returns for the ODBC C-API function SQLDescribeCol we >>>>> could know if the driver is at fault or if the odbc-port program is. >>>>> >>>>> Regards ?Ingela Erlang/OTP team - Ericsson AB >>>>> >>>>> 2011/5/1 Hanfei Shen : >>>>> >>>>>> >>>>>> Dear all, >>>>>> >>>>>> I'm a newbie programming in erlang. When I used ODBC to connect to a >>>>>> MySQL database through Connector/ODBC (MyODBC), I got some error when >>>>>> calling odbc:sql_query(Conn, "SELECT * FROM action"): >>>>>> >>>>>> {error,"Column type not supported"} >>>>>> >>>>>> Then I call odbc:describe_table(Conn, "action"), it returned: >>>>>> >>>>>> {ok,[{"id",sql_integer}, >>>>>> ? ? {"code",'ODBC_UNSUPPORTED_TYPE'}, >>>>>> ? ? {"compliment_desc",'ODBC_UNSUPPORTED_TYPE'}, >>>>>> ? ? {"status_desc",'ODBC_UNSUPPORTED_TYPE'}, >>>>>> ? ? {"parameter",'ODBC_UNSUPPORTED_TYPE'}, >>>>>> ? ? {"cause",'ODBC_UNSUPPORTED_TYPE'}, >>>>>> ? ? {"disabled",sql_tinyint}]} >>>>>> >>>>>> And desc the table in mysql client: >>>>>> mysql> desc action; >>>>>> >>>>>> +-----------------+--------------+------+-----+---------+----------------+ >>>>>> | Field ? ? ? ? ? | Type ? ? ? ? | Null | Key | Default | Extra >>>>>> ?| >>>>>> >>>>>> +-----------------+--------------+------+-----+---------+----------------+ >>>>>> | id ? ? ? ? ? ? ?| int(11) ? ? ?| NO ? | PRI | NULL ? ?| auto_increment >>>>>> | >>>>>> | code ? ? ? ? ? ?| varchar(255) | NO ? | ? ? | NULL ? ?| >>>>>> ?| >>>>>> | compliment_desc | varchar(255) | NO ? | ? ? | ? ? ? ? | >>>>>> ?| >>>>>> | status_desc ? ? | varchar(255) | NO ? | ? ? | ? ? ? ? | >>>>>> ?| >>>>>> | parameter ? ? ? | varchar(255) | NO ? | ? ? | ? ? ? ? | >>>>>> ?| >>>>>> | cause ? ? ? ? ? | varchar(255) | NO ? | UNI | ? ? ? ? | >>>>>> ?| >>>>>> | disabled ? ? ? ?| tinyint(1) ? | NO ? | ? ? | 0 ? ? ? | >>>>>> ?| >>>>>> >>>>>> +-----------------+--------------+------+-----+---------+----------------+ >>>>>> >>>>>> It seems that Erlang ODBC driver does not support the mysql type >>>>>> varchar? How can I use the database without touching the db schema? >>>>>> >>>>>> >>>>>> Some details about the system env: >>>>>> >>>>>> $ uname -a >>>>>> Linux 2.6.36-gentoo-r8 #4 SMP Thu Apr 7 20:13:18 CST 2011 x86_64 >>>>>> Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz GenuineIntel GNU/Linux >>>>>> >>>>>> $ erl >>>>>> Erlang R13B04 (erts-5.7.5) [source] [64-bit] [smp:2:2] [rq:2] >>>>>> [async-threads:0] [kernel-poll:false] >>>>>> >>>>>> $ emerge -vp erlang >>>>>> dev-lang/erlang-13.2.4 ?USE="doc kpoll odbc smp ssl -emacs -hipe -java >>>>>> -sctp -tk -wxwidgets" >>>>>> >>>>>> eshell> code:which(odbc). >>>>>> "/usr/lib64/erlang/lib/odbc-2.10.7/ebin/odbc.beam" >>>>>> >>>>>> $ mysql -V >>>>>> mysql ?Ver 14.14 Distrib 5.1.51, for pc-linux-gnu (x86_64) using >>>>>> readline 5.1 >>>>>> >>>>>> Server version: 5.1.51-log Gentoo Linux mysql-5.1.51 >>>>>> >>>>>> $ emerge -vp myodbc >>>>>> dev-db/myodbc-5.1.6 ?USE="-debug -doc -qt4 -static" >>>>>> >>>>>> >>>>>> Any help will be greatly appreciated. ?Thanks in advance. >>>>>> Sorry for my poor English, I'm not a native... >>>>>> >>>>>> Best, >>>>>> >>>>>> -- >>>>>> Hanfei >>>>>> _______________________________________________ >>>>>> erlang-questions mailing list >>>>>> erlang-questions@REDACTED >>>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>>>> >>>>>> >>>> >>>> >>> >>> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > From qqshfox@REDACTED Mon May 2 18:27:23 2011 From: qqshfox@REDACTED (Hanfei Shen) Date: Tue, 3 May 2011 00:27:23 +0800 Subject: [erlang-questions] Erlang and MySQL: ODBC, Column type not supported In-Reply-To: References: <4DBE7B49.1080505@erix.ericsson.se> Message-ID: Hi, Hmmmmmm... The unixODBC is already in my system, but I don't know how to use it... I will setup a vm with fresh system tomorrow to reproduce the problem... PS, could you figure out a name of ANOTHER ODBC-DRIVER which you mentioned? 2011/5/3 Hanfei Shen : > Hi, > > I've tried https://github.com/dizzyd/erlang-mysql-driver, it works. > > I'm installing unixodbc... Wait a minute. Thnx... > > > 2011/5/3 Ingela Andin : >> Hi! >> >> Well the best thing would be if you can provide me with a way to reproduce it. >> Do you have the possibility to try another odbc-driver with your database? >> >> Regards Ingela Erlang/OTP team - Ericsson AB >> >> >> 2011/5/2 Hanfei Shen : >>> Hi, >>> >>> I had changed the type from SQLINTEGER to SQLSMALLINT, but the problem >>> is still there... >>> >>> (gdb) i func encode_data_type >>> File odbcserver.c: >>> static void encode_data_type(SQLSMALLINT, SQLINTEGER, SQLSMALLINT, db_state *); >>> >>> Breakpoint 1, encode_data_type (sql_type=-9, size=255, >>> decimal_digits=0, state=0x7fffa5380210) at odbcserver.c:1396 >>> 1396 ? ? ? ?switch(sql_type) { >>> >>> Do you need any details? >>> >>> 2011/5/2 Ingela Anderton Andin : >>>> Hi! >>>> >>>> Hanfei Shen wrote: >>>>> >>>>> Hi Ingela, >>>>> >>>>> Did you mean the value of variable "sql_type"? >>>>> >>>>> >>>> >>>> Yes. >>>> >>>>> I tried to inspect it through gdb, setting a break on func >>>>> encode_data_type. And then I got: >>>>> >>>>> Breakpoint 1, encode_data_type (sql_type=-9, size=255, >>>>> decimal_digits=0, state=0x7fffc657ec40) at odbcserver.c:1396 >>>>> 1396 ? ? ? ?switch(sql_type) { >>>>> >>>>> >>>> >>>> Well that is defenetly not a good value. Looking at the code just now >>>> I noticed that >>>> >>>> encode_data_type defines sql_type as "SQLINTEGER sql_type" and it >>>> ought to be "SQLSMALLINT sql_type". If you change that does it fix your >>>> problem? >>>> >>>> Regards Ingela Erlang/OTP team - Ericsson AB >>>> >>>> >>>> >>>>> 2011/5/2 Ingela Andin : >>>>> >>>>>> >>>>>> Hi! >>>>>> >>>>>> The erlang odbc application supports {sql-varchars, ?N} where N = 255 >>>>>> in your case. The return values >>>>>> you get suggest that the odbc-driver you have returns an unexpected >>>>>> column type. >>>>>> >>>>>> In the erlang odbc port program there is a switch that handles type >>>>>> when describing a coloumn that if we take out >>>>>> the handling code looks like this. >>>>>> >>>>>> switch(sql_type) { >>>>>> ? case SQL_CHAR: >>>>>> ? case SQL_VARCHAR: >>>>>> ? case SQL_WCHAR: >>>>>> ? case SQL_WVARCHAR: >>>>>> ? case SQL_NUMERIC: >>>>>> ? case SQL_DECIMAL: >>>>>> ? case SQL_INTEGER: >>>>>> ? case SQL_TINYINT: >>>>>> ? case SQL_SMALLINT: >>>>>> ? case SQL_REAL: >>>>>> ? case SQL_FLOAT: >>>>>> ? case SQL_DOUBLE: >>>>>> ? case SQL_BIT: >>>>>> ? case SQL_TYPE_DATE: >>>>>> ? case SQL_TYPE_TIME: >>>>>> ? case SQL_TYPE_TIMESTAMP: >>>>>> ? case SQL_BIGINT: >>>>>> ? case SQL_BINARY: >>>>>> ? case SQL_LONGVARCHAR: >>>>>> ? case SQL_VARBINARY: >>>>>> ? case SQL_LONGVARBINARY: >>>>>> ? case SQL_INTERVAL_MONTH: >>>>>> ? case SQL_INTERVAL_YEAR: >>>>>> ? case SQL_INTERVAL_DAY: >>>>>> ? case SQL_INTERVAL_MINUTE: >>>>>> ? case SQL_INTERVAL_HOUR_TO_SECOND: >>>>>> ? case SQL_INTERVAL_MINUTE_TO_SECOND: >>>>>> ? case SQL_UNKNOWN_TYPE: >>>>>> ? default: /* Will probably never happen */ >>>>>> ? ? ? ei_x_encode_atom(&dynamic_buffer(state), "ODBC_UNSUPPORTED_TYPE"); >>>>>> ? ? ? break; >>>>>> ? } >>>>>> >>>>>> >>>>>> And you end up in the default clause which is very unexpected and the >>>>>> root to your problem. ?If ?you can figur out >>>>>> what your driver returns for the ODBC C-API function SQLDescribeCol we >>>>>> could know if the driver is at fault or if the odbc-port program is. >>>>>> >>>>>> Regards ?Ingela Erlang/OTP team - Ericsson AB >>>>>> >>>>>> 2011/5/1 Hanfei Shen : >>>>>> >>>>>>> >>>>>>> Dear all, >>>>>>> >>>>>>> I'm a newbie programming in erlang. When I used ODBC to connect to a >>>>>>> MySQL database through Connector/ODBC (MyODBC), I got some error when >>>>>>> calling odbc:sql_query(Conn, "SELECT * FROM action"): >>>>>>> >>>>>>> {error,"Column type not supported"} >>>>>>> >>>>>>> Then I call odbc:describe_table(Conn, "action"), it returned: >>>>>>> >>>>>>> {ok,[{"id",sql_integer}, >>>>>>> ? ? {"code",'ODBC_UNSUPPORTED_TYPE'}, >>>>>>> ? ? {"compliment_desc",'ODBC_UNSUPPORTED_TYPE'}, >>>>>>> ? ? {"status_desc",'ODBC_UNSUPPORTED_TYPE'}, >>>>>>> ? ? {"parameter",'ODBC_UNSUPPORTED_TYPE'}, >>>>>>> ? ? {"cause",'ODBC_UNSUPPORTED_TYPE'}, >>>>>>> ? ? {"disabled",sql_tinyint}]} >>>>>>> >>>>>>> And desc the table in mysql client: >>>>>>> mysql> desc action; >>>>>>> >>>>>>> +-----------------+--------------+------+-----+---------+----------------+ >>>>>>> | Field ? ? ? ? ? | Type ? ? ? ? | Null | Key | Default | Extra >>>>>>> ?| >>>>>>> >>>>>>> +-----------------+--------------+------+-----+---------+----------------+ >>>>>>> | id ? ? ? ? ? ? ?| int(11) ? ? ?| NO ? | PRI | NULL ? ?| auto_increment >>>>>>> | >>>>>>> | code ? ? ? ? ? ?| varchar(255) | NO ? | ? ? | NULL ? ?| >>>>>>> ?| >>>>>>> | compliment_desc | varchar(255) | NO ? | ? ? | ? ? ? ? | >>>>>>> ?| >>>>>>> | status_desc ? ? | varchar(255) | NO ? | ? ? | ? ? ? ? | >>>>>>> ?| >>>>>>> | parameter ? ? ? | varchar(255) | NO ? | ? ? | ? ? ? ? | >>>>>>> ?| >>>>>>> | cause ? ? ? ? ? | varchar(255) | NO ? | UNI | ? ? ? ? | >>>>>>> ?| >>>>>>> | disabled ? ? ? ?| tinyint(1) ? | NO ? | ? ? | 0 ? ? ? | >>>>>>> ?| >>>>>>> >>>>>>> +-----------------+--------------+------+-----+---------+----------------+ >>>>>>> >>>>>>> It seems that Erlang ODBC driver does not support the mysql type >>>>>>> varchar? How can I use the database without touching the db schema? >>>>>>> >>>>>>> >>>>>>> Some details about the system env: >>>>>>> >>>>>>> $ uname -a >>>>>>> Linux 2.6.36-gentoo-r8 #4 SMP Thu Apr 7 20:13:18 CST 2011 x86_64 >>>>>>> Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz GenuineIntel GNU/Linux >>>>>>> >>>>>>> $ erl >>>>>>> Erlang R13B04 (erts-5.7.5) [source] [64-bit] [smp:2:2] [rq:2] >>>>>>> [async-threads:0] [kernel-poll:false] >>>>>>> >>>>>>> $ emerge -vp erlang >>>>>>> dev-lang/erlang-13.2.4 ?USE="doc kpoll odbc smp ssl -emacs -hipe -java >>>>>>> -sctp -tk -wxwidgets" >>>>>>> >>>>>>> eshell> code:which(odbc). >>>>>>> "/usr/lib64/erlang/lib/odbc-2.10.7/ebin/odbc.beam" >>>>>>> >>>>>>> $ mysql -V >>>>>>> mysql ?Ver 14.14 Distrib 5.1.51, for pc-linux-gnu (x86_64) using >>>>>>> readline 5.1 >>>>>>> >>>>>>> Server version: 5.1.51-log Gentoo Linux mysql-5.1.51 >>>>>>> >>>>>>> $ emerge -vp myodbc >>>>>>> dev-db/myodbc-5.1.6 ?USE="-debug -doc -qt4 -static" >>>>>>> >>>>>>> >>>>>>> Any help will be greatly appreciated. ?Thanks in advance. >>>>>>> Sorry for my poor English, I'm not a native... >>>>>>> >>>>>>> Best, >>>>>>> >>>>>>> -- >>>>>>> Hanfei >>>>>>> _______________________________________________ >>>>>>> erlang-questions mailing list >>>>>>> erlang-questions@REDACTED >>>>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>>>>> >>>>>>> >>>>> >>>>> >>>> >>>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >> > From mrtndimitrov@REDACTED Mon May 2 18:38:40 2011 From: mrtndimitrov@REDACTED (Martin Dimitrov) Date: Mon, 2 May 2011 19:38:40 +0300 (EEST) Subject: [erlang-questions] supervisor:start_child Message-ID: <1776904681.834392.1304354320093.JavaMail.apache@nm2.abv.bg> Thanks for the advise about the interface. > A normal (i.e. not simple_on_for_one) supervisor allows you to stop, restart and delete children processes, so it needs a way to identify them. Hence the id. Isn't the process id the natural choice for these purposes? So there is no way to avoid the need of unique ids if using anything other than simple_one_for_one? Regards, Martin -------- ?????????? ????? -------- ??: Mihai Balea mihai@REDACTED ???????: Re: [erlang-questions] supervisor:start_child ??: Martin Dimitrov ????????? ??: ??????????, 2011, ??? 2 19:13:16 EEST On May 2, 2011, at 8:32 AM, Martin Dimitrov wrote: > Hi, > > I am developing a server that needs to spawn (under supervision) multiple child processes. Since these processes will be of different gen_server type, I cannot use simple_one_of_one restart strategy. These servers are anonymous, I refer to them by their Pids. I think you might be able to use a simple one for one supervisor to start different types of gen_servers. You would need to create an interface module to be used in the child spec, a module that would in turn call your various other gen_servers according to some parameters. I've never done this, but I don't see why it wouldn't work. > > The problem I get is when I try to run 2 or more servers from the same type with the same id inside the child specification. I receive already_started error. By making the ids different, everything works fine. > > My question is why the id inside the child specification needs to be different for every process (even if it is of the same type)? What is the best practice to deal with this? Can the creation of dynamic ids be avoided? A normal (i.e. not simple_on_for_one) supervisor allows you to stop, restart and delete children processes, so it needs a way to identify them. Hence the id. Mihai -------------- next part -------------- An HTML attachment was scrubbed... URL: From gregory.haskins@REDACTED Mon May 2 19:17:23 2011 From: gregory.haskins@REDACTED (Gregory Haskins) Date: Mon, 02 May 2011 13:17:23 -0400 Subject: [erlang-questions] supervisor:start_child In-Reply-To: <1776904681.834392.1304354320093.JavaMail.apache@nm2.abv.bg> References: <1776904681.834392.1304354320093.JavaMail.apache@nm2.abv.bg> Message-ID: <4DBEE723.2070902@gmail.com> On 5/2/11 12:38 PM, Martin Dimitrov wrote: > Thanks for the advise about the interface. > >> A normal (i.e. not simple_on_for_one) supervisor allows you to stop, > restart and delete children processes, so it needs a way to identify > them. Hence the id. > > Isn't the process id the natural choice for these purposes? Its chicken and egg, though. The supervisor spawns the process and you have to give it an ID to instruct it to start_child() in the first place. > > So there is no way to avoid the need of unique ids if using anything > other than simple_one_for_one? When I don't care, I just use erlang:now() for the ID. Sloppy, perhaps, but it gets the job done. Kind Regards, -Greg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 267 bytes Desc: OpenPGP digital signature URL: From alex.arnon@REDACTED Mon May 2 20:24:31 2011 From: alex.arnon@REDACTED (Alex Arnon) Date: Mon, 2 May 2011 21:24:31 +0300 Subject: [erlang-questions] Looking for RDBMS driver with Transaction Support. Message-ID: Hi All, Is there an RDBMS driver in the Erlang universe whose API supports transactions? The docs for odbc, epgsql and emysql do not specify any kind of transaction support. Thanks in advance! -------------- next part -------------- An HTML attachment was scrubbed... URL: From moxford@REDACTED Mon May 2 20:25:57 2011 From: moxford@REDACTED (Mike Oxford) Date: Mon, 2 May 2011 11:25:57 -0700 Subject: [erlang-questions] supervisor:start_child In-Reply-To: <4DBEE723.2070902@gmail.com> References: <1776904681.834392.1304354320093.JavaMail.apache@nm2.abv.bg> <4DBEE723.2070902@gmail.com> Message-ID: You can also "not register" them, either locally or globally. In your child's start_link, use the gen_server/3 instead of gen_server/4. You cannot do a "whereis(service)" type call, but your children will run and you won't get the conflicting IDs. -mox On Mon, May 2, 2011 at 10:17 AM, Gregory Haskins wrote: > On 5/2/11 12:38 PM, Martin Dimitrov wrote: > > Thanks for the advise about the interface. > > > >> A normal (i.e. not simple_on_for_one) supervisor allows you to stop, > > restart and delete children processes, so it needs a way to identify > > them. Hence the id. > > > > Isn't the process id the natural choice for these purposes? > > Its chicken and egg, though. The supervisor spawns the process and you > have to give it an ID to instruct it to start_child() in the first place. > > > > > So there is no way to avoid the need of unique ids if using anything > > other than simple_one_for_one? > > When I don't care, I just use erlang:now() for the ID. Sloppy, perhaps, > but it gets the job done. > > Kind Regards, > -Greg > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrtndimitrov@REDACTED Mon May 2 20:30:39 2011 From: mrtndimitrov@REDACTED (Martin Dimitrov) Date: Mon, 2 May 2011 21:30:39 +0300 (EEST) Subject: [erlang-questions] supervisor:start_child Message-ID: <2949165.1632990.1304361039304.JavaMail.apache@nm1.abv.bg> > You can also "not register" them, either locally or globally. In your child's start_link, use the gen_server/3 instead of gen_server/4. I do this but when using the same id for the specification, I receive already_started error. I believe both need to be unique but my question is why. Regards, Martin -------- ?????????? ????? -------- ??: Mike Oxford moxford@REDACTED ???????: Re: [erlang-questions] supervisor:start_child ??: Gregory Haskins ????????? ??: ??????????, 2011, ??? 2 21:25:57 EEST You can also "not register" them, either locally or globally. In your child's start_link, use the gen_server/3 instead of gen_server/4. You cannot do a "whereis(service)" type call, but your children will run and you won't get the conflicting IDs. -mox On Mon, May 2, 2011 at 10:17 AM, Gregory Haskins gregory.haskins@REDACTED > wrote: On 5/2/11 12:38 PM, Martin Dimitrov wrote: > Thanks for the advise about the interface. > >> A normal (i.e. not simple_on_for_one) supervisor allows you to stop, > restart and delete children processes, so it needs a way to identify > them. Hence the id. > > Isn't the process id the natural choice for these purposes? Its chicken and egg, though. The supervisor spawns the process and you have to give it an ID to instruct it to start_child() in the first place. > > So there is no way to avoid the need of unique ids if using anything > other than simple_one_for_one? When I don't care, I just use erlang:now() for the ID. Sloppy, perhaps, but it gets the job done. Kind Regards, -Greg _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf.wiger@REDACTED Mon May 2 20:41:21 2011 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Mon, 2 May 2011 20:41:21 +0200 Subject: [erlang-questions] Looking for RDBMS driver with Transaction Support. In-Reply-To: References: Message-ID: <30E8AA2D-37A6-4696-8506-94A85690EB1C@erlang-solutions.com> On 2 May 2011, at 20:24, Alex Arnon wrote: > Hi All, > > Is there an RDBMS driver in the Erlang universe whose API supports transactions? > The docs for odbc, epgsql and emysql do not specify any kind of transaction support. Erlydb had transaction support, and some people may still be using it. https://github.com/anka-213/erlydb http://yarivsblog.blogspot.com/2006/09/erlydb-07.html ODBC actually does too. You use odbc:connect/2 followed by odbc:commit/2, unless you have {auto_commit, on}, in which case every query is a transaction. BR, Ulf W Ulf Wiger, CTO, Erlang Solutions, Ltd. http://erlang-solutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ixmatus@REDACTED Mon May 2 20:43:07 2011 From: ixmatus@REDACTED (Parnell Springmeyer) Date: Mon, 02 May 2011 11:43:07 -0700 Subject: [erlang-questions] Looking for RDBMS driver with Transaction Support. In-Reply-To: (Alex Arnon's message of "Mon, 2 May 2011 21:24:31 +0300") References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 https://github.com/dizzyd/erlang-mysql-driver Look at the tests to see how transactions are used. I use them extensively in my current project. Alex Arnon writes: > Hi All, > > Is there an RDBMS driver in the Erlang universe whose API supports > transactions? > The docs for odbc, epgsql and emysql do not specify any kind of > transaction support. > > Thanks in advance! > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions - -- Parnell "ixmatus" Springmeyer (http://ixmat.us) -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNvvs7AAoJEPvtlbpI1POLvQcH/jyrjTekFE3P0FeF6dn84ROo mAQQWI0cKGM8gLJOJA0kzaf3kEOZ4Ad6qBot2cXU1W5jWBDxRdf0DcvlsGCXx7uN fNOfLCug6/3NNICkCjTUu+mtE1zs3itxj4LU87fbNe9h65MelASwQh7NnXob11A2 5ylQBXgzEdv6AaPavdO/ej9qRNDA0QieVTFaECW0Pzaly87q9XkBqkgQqoFt34Ta eAbewn90VhuQKB1GZZJDUOH58l57H2RaMKUqSqYMCCmqxwXXAmNUKyNYOsurx7za gCjSEBZ7JvCb+3yyLj6SWlHgTFypYNtZK+861lNLd8i2aKPsOuWHIo/9pkprO94= =PPX8 -----END PGP SIGNATURE----- From alex.arnon@REDACTED Mon May 2 21:18:11 2011 From: alex.arnon@REDACTED (Alex Arnon) Date: Mon, 2 May 2011 22:18:11 +0300 Subject: [erlang-questions] Looking for RDBMS driver with Transaction Support. In-Reply-To: References: Message-ID: Thank you all for the solutions, this is very helpful! We will evaluate the epgsql and erlang-mysql solutions. On Mon, May 2, 2011 at 9:43 PM, Parnell Springmeyer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > https://github.com/dizzyd/erlang-mysql-driver > > Look at the tests to see how transactions are used. I use them > extensively in my current project. > > Alex Arnon writes: > > > Hi All, > > > > Is there an RDBMS driver in the Erlang universe whose API supports > > transactions? > > The docs for odbc, epgsql and emysql do not specify any kind of > > transaction support. > > > > Thanks in advance! > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > - -- > Parnell "ixmatus" Springmeyer (http://ixmat.us) > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > > iQEcBAEBAgAGBQJNvvs7AAoJEPvtlbpI1POLvQcH/jyrjTekFE3P0FeF6dn84ROo > mAQQWI0cKGM8gLJOJA0kzaf3kEOZ4Ad6qBot2cXU1W5jWBDxRdf0DcvlsGCXx7uN > fNOfLCug6/3NNICkCjTUu+mtE1zs3itxj4LU87fbNe9h65MelASwQh7NnXob11A2 > 5ylQBXgzEdv6AaPavdO/ej9qRNDA0QieVTFaECW0Pzaly87q9XkBqkgQqoFt34Ta > eAbewn90VhuQKB1GZZJDUOH58l57H2RaMKUqSqYMCCmqxwXXAmNUKyNYOsurx7za > gCjSEBZ7JvCb+3yyLj6SWlHgTFypYNtZK+861lNLd8i2aKPsOuWHIo/9pkprO94= > =PPX8 > -----END PGP SIGNATURE----- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jameschurchman@REDACTED Mon May 2 21:43:33 2011 From: jameschurchman@REDACTED (James Churchman) Date: Mon, 2 May 2011 20:43:33 +0100 Subject: [erlang-questions] byte() vs. char() use in documentation In-Reply-To: <4DBE83B4.50501@cs.ntua.gr> References: <20110502091415.GA6512@erix.ericsson.se> <372726991.139721304328918708.JavaMail.root@zimbra> <20110502095824.GA9576@erix.ericsson.se> <4DBE83B4.50501@cs.ntua.gr> Message-ID: So just for my own understanding, and as it seems extremely important ( strings are quite important these days!), as it stands now: iolists cant can only ( officially?) contain utf8? ( as no utf8 code point will exceed 255, like latin1 / asci, and are therefor are all byte() ) strings can be of utf8 utf16 or utf32, but only the utf8 version is allowed in an iolist? ( and therefore if you wanted an "iolist" ( eg a non flat list of chars) that contained utf 16 or 32 code points you would have to stick exclusively to lists ( strings) and not binaries and use lists:flatten before you finished with it, to remove all the nested lists ) binaries can be of any unicode type.. also there does seem to be a needed distinction between char() and byte() as they are not the same at all, but the documentation is wrong as at the moment iolists can infact only contain byte() not char() the suggested direction is to repair the docs so that they specify only allowing 0~255 ints( byte() ) in iolists rather than allowing io-lists to contain any string as they did before the introduction of unicode / in the days of latin1 etc.. ? i think that that goes agents most ( even erlang implementers :-) ) opinion of what an iolist is ( that being a list of any valid string or binary) but maybe ( to raise a totally different problem) would prevent the possibility of an iolist having a mixed unicode type and still begin "valid" ( even tho i guess this is still possible as binaries can in fact be other utf representations) On 2 May 2011 11:13, Kostis Sagonas wrote: > Raimo Niskanen wrote: > >> >> This became messy when char() was re-defined from latin-1 character >> to unicode character. That affected string() that affected iolist() >> and the latter was incorrect. >> >> We must clean up the mess. >> > > Right. The sooner it happens the better it is. > > ... Either by completing the notion of char() >> >> being unicode and hence rewriting iolist() to contain byte() and binary(), >> or by reverting to char() being latin-1 char and using unicode:char() >> and unicode:string() where that is correct... >> > > Please, by all means do the former. The latter will only cause havoc > everywhere. For starters, I do not see any need in having two different > basic types (byte() and char()) denoting (pretty much) the same thing. The > only thing this does is cause unnecessary confusion to newcomers (and > apparently to some old-timers too). Second, if you choose the latter you > will eventually have to change lots of type inference code, because I > promise you I will not do this, and believe me you don't want to go there... > (The Vietnam jungle is probably a friendlier place ;) ) > > Cheers, > Kostis > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gregory.haskins@REDACTED Mon May 2 21:43:31 2011 From: gregory.haskins@REDACTED (Gregory Haskins) Date: Mon, 02 May 2011 15:43:31 -0400 Subject: [erlang-questions] supervisor:start_child In-Reply-To: <2949165.1632990.1304361039304.JavaMail.apache@nm1.abv.bg> References: <2949165.1632990.1304361039304.JavaMail.apache@nm1.abv.bg> Message-ID: <4DBF0963.5070801@gmail.com> On 5/2/11 2:30 PM, Martin Dimitrov wrote: >> You can also "not register" them, either locally or globally. In your > child's start_link, use the gen_server/3 instead of gen_server/4. > > I do this but when using the same id for the specification, I receive > already_started error. I believe both need to be unique but my question > is why. The supervisor ID is a "supref" name-space that uniquely identifies the _childspec_, so that it may be later referred to with terminate_child(), delete_child(), and restart_child(). The first parameter in gen_server:start_link/4 is a process namespace (actually, two: global and local) that uniquely identifies the _pid_. In both cases, the name given _must_ be unique, though you can opt not to specify a name in the pid namespace by using gen_server/3. As far as I know, you must always specify a name in the supref namespace, though you can use a throw-away value (like erlang:now()) if you don't ever care to terminate/delete/restart that particular child (at least via the supervisor module). So to answer your question, they both must be unique simply because the namespaces in question do not allow duplicate entries. However, the namespaces do not really relate to one another, and one of them is optional (i.e. via use of gen_server/3). Hope that helps, -Greg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 267 bytes Desc: OpenPGP digital signature URL: From silent_vendetta@REDACTED Mon May 2 21:50:17 2011 From: silent_vendetta@REDACTED (Chris Hicks) Date: Mon, 2 May 2011 12:50:17 -0700 Subject: [erlang-questions] QLC question In-Reply-To: <4DBEC67D.20405@gmail.com> References: <4DBE4731.4030609@gmail.com> <4DBE6CA3.3000109@ubiquity.it>, , <4DBEC67D.20405@gmail.com> Message-ID: I've got a record nested within a record like this: {account_wrapper, "Username", {account_data, ...}} And what I want to do is use QLC to search that inner record and see if someone already has chosen a nickname for an account during registration. However, since I've never used QLC before I wanted to start out slow and just get a feel, creating more complex QLC's as I went along until I got where I wanted to go. First I tried this: mnesia:activity(transaction, fun() -> qlc:eval(qlc:q([{A, B, C} || Wrapper <- mnesia:table(accounts), {A, B, C} <- Wrapper])) end, []). I just wanted to make sure I understood how to unpack data structures...however I keep getting a qlc error: ** exception exit: {aborted,{badarg,[{qlc,eval, [{error,qlc, {1,qlc,{used_generator_variable,'Wrapper'}}}, []]}, {mnesia_tm,apply_fun,3}, {mnesia_tm,execute_transaction,5}, {mnesia,wrap_trans,6}, {erl_eval,do_apply,5}, {shell,exprs,7}, {shell,eval_exprs,7}, {shell,eval_loop,3}]}} in function mnesia:wrap_trans/6 Now from everything I've read...I thought I'd be able to use the Wrapper variable later on in the query as a generator...thus allowing me to unpack things. Why would this be giving me an error? If I change it to: mnesia:activity(transaction, fun() -> qlc:eval(qlc:q([{A, B, C} || {A, B, C} <- mnesia:table(accounts)])) end, []). It works just fine and returns the record...and I can successfully match the pattern {A, B, C} with the account_wrapper record elsewhere. So what am I missing? Chris Hicks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay@REDACTED Mon May 2 21:50:29 2011 From: jay@REDACTED (Jay Nelson) Date: Mon, 2 May 2011 12:50:29 -0700 Subject: [erlang-questions] erlang-bugs reports not showing in list Message-ID: <0FC1E82D-91D3-4ADA-BAA5-F7A805DD30EB@duomark.com> I am not registered as an individual to be a member of erlang-bugs, but I have sent 2 emails in the last month (March re: reltool and rebar, today re: dialyzer and binary:compile/1) that have not shown up on the list. Are they automatically dropped by the email management system if you are not a member of the list? jay From ulf.wiger@REDACTED Mon May 2 22:11:51 2011 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Mon, 2 May 2011 22:11:51 +0200 Subject: [erlang-questions] QLC question In-Reply-To: References: <4DBE4731.4030609@gmail.com> <4DBE6CA3.3000109@ubiquity.it>, , <4DBEC67D.20405@gmail.com> Message-ID: <24215C0A-394C-4E8E-8297-F465068ED299@erlang-solutions.com> If you have a record within a record, you can simply use pattern matching: 1> rd(data, {id, nick}). data 2> rd(wrapper, {id, data}). wrapper 3> L = [#wrapper{id=1,data=#data{id=1}}, #wrapper{id=2,data=#data{id=2,nick=n}}]. [#wrapper{id = 1,data = #data{id = 1,nick = undefined}}, #wrapper{id = 2,data = #data{id = 2,nick = n}}] 4> qlc:e(qlc:q([W || #wrapper{data = #data{nick = N}} = W <- L, N =/= undefined])). [#wrapper{id = 2,data = #data{id = 2,nick = n}}] If this becomes to hairy, you can use a guard function which does deep inspection on the record. In LCs, a guard function can be any Erlang function. A generator in QLC must either be a list, or a special QLC generator (e.g. what you get as a return value from qlc:q/1 or mnesia:table/1). In this particular case, QLC seems to complain already in the query analysis stage, as it doesn't like the fact that a dynamic variable is assumed to be a valid generator. BR, Ulf W On 2 May 2011, at 21:50, Chris Hicks wrote: > I've got a record nested within a record like this: > > {account_wrapper, "Username", {account_data, ...}} > > And what I want to do is use QLC to search that inner record and see if someone already has chosen a nickname for an account during registration. However, since I've never used QLC before I wanted to start out slow and just get a feel, creating more complex QLC's as I went along until I got where I wanted to go. First I tried this: > > mnesia:activity(transaction, fun() -> qlc:eval(qlc:q([{A, B, C} || Wrapper <- mnesia:table(accounts), {A, B, C} <- Wrapper])) end, []). > > I just wanted to make sure I understood how to unpack data structures...however I keep getting a qlc error: > > ** exception exit: {aborted,{badarg,[{qlc,eval, > [{error,qlc, > {1,qlc,{used_generator_variable,'Wrapper'}}}, > []]}, > {mnesia_tm,apply_fun,3}, > {mnesia_tm,execute_transaction,5}, > {mnesia,wrap_trans,6}, > {erl_eval,do_apply,5}, > {shell,exprs,7}, > {shell,eval_exprs,7}, > {shell,eval_loop,3}]}} > in function mnesia:wrap_trans/6 > > > Now from everything I've read...I thought I'd be able to use the Wrapper variable later on in the query as a generator...thus allowing me to unpack things. Why would this be giving me an error? If I change it to: > > mnesia:activity(transaction, fun() -> qlc:eval(qlc:q([{A, B, C} || {A, B, C} <- mnesia:table(accounts)])) end, []). > > It works just fine and returns the record...and I can successfully match the pattern {A, B, C} with the account_wrapper record elsewhere. So what am I missing? > > Chris Hicks. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions Ulf Wiger, CTO, Erlang Solutions, Ltd. http://erlang-solutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrtndimitrov@REDACTED Mon May 2 22:19:59 2011 From: mrtndimitrov@REDACTED (Martin Dimitrov) Date: Mon, 2 May 2011 23:19:59 +0300 (EEST) Subject: [erlang-questions] supervisor:start_child Message-ID: <1424119010.1804752.1304367599050.JavaMail.apache@nm3.abv.bg> Thanks for the explanation. In our app we actually use the sup functions (delete_child and so on) but we keep only the pids and since the relationship is one-to-one we retrieve the dynamic id. I thought that there might be an easier way but from what I understand now there isn't. Thank you all for the help. Regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From silent_vendetta@REDACTED Mon May 2 22:39:21 2011 From: silent_vendetta@REDACTED (Chris Hicks) Date: Mon, 2 May 2011 13:39:21 -0700 Subject: [erlang-questions] QLC question In-Reply-To: <24215C0A-394C-4E8E-8297-F465068ED299@erlang-solutions.com> References: <4DBE4731.4030609@gmail.com> <4DBE6CA3.3000109@ubiquity.it>, , <4DBEC67D.20405@gmail.com> , <24215C0A-394C-4E8E-8297-F465068ED299@erlang-solutions.com> Message-ID: Makes sense, I'll certainly be playing around with it a lot more, learning via failure and all that. I ended up figuring out how to what I was actually working towards but I'd like to open myself to criticism and see if there is anything about the QLC that could be improved. Here is the code: mnesia:activity(transaction, fun(Nickname) -> qlc:eval(qlc:q([Exists || {A, B, C, D} <- mnesia:table(emuf_accounts), Exists = ((emuf_crypt:decrypt(D))#account_data.nickname == Nickname)])) end, [N]) Now, the emuf_decrypt call is to my own module/function which handles the encrypting/decrypting of my data, so that I'm not storing any user account information in the open (except, of course, the Username but this should be plenty secure in my case). The data has to be decrypted each time it is read, of course. Is this a naive solution? Is there anything about it that might slowdown the query or is there just a plain more efficient way of doing it? Chris Hicks. Subject: Re: [erlang-questions] QLC question From: ulf.wiger@REDACTED Date: Mon, 2 May 2011 22:11:51 +0200 CC: erlang-questions@REDACTED To: silent_vendetta@REDACTED If you have a record within a record, you can simply use pattern matching: 1> rd(data, {id, nick}).data2> rd(wrapper, {id, data}).wrapper 3> L = [#wrapper{id=1,data=#data{id=1}}, #wrapper{id=2,data=#data{id=2,nick=n}}].[#wrapper{id = 1,data = #data{id = 1,nick = undefined}}, #wrapper{id = 2,data = #data{id = 2,nick = n}}] 4> qlc:e(qlc:q([W || #wrapper{data = #data{nick = N}} = W <- L, N =/= undefined])).[#wrapper{id = 2,data = #data{id = 2,nick = n}}] If this becomes to hairy, you can use a guard function which does deep inspection on the record. In LCs, a guard function can be any Erlang function. A generator in QLC must either be a list, or a special QLC generator (e.g. what you get as a return value from qlc:q/1 or mnesia:table/1). In this particular case, QLC seems to complain already in the query analysis stage, as it doesn't like the fact that a dynamic variable is assumed to be a valid generator. BR,Ulf W On 2 May 2011, at 21:50, Chris Hicks wrote:I've got a record nested within a record like this: {account_wrapper, "Username", {account_data, ...}} And what I want to do is use QLC to search that inner record and see if someone already has chosen a nickname for an account during registration. However, since I've never used QLC before I wanted to start out slow and just get a feel, creating more complex QLC's as I went along until I got where I wanted to go. First I tried this: mnesia:activity(transaction, fun() -> qlc:eval(qlc:q([{A, B, C} || Wrapper <- mnesia:table(accounts), {A, B, C} <- Wrapper])) end, []). I just wanted to make sure I understood how to unpack data structures...however I keep getting a qlc error: ** exception exit: {aborted,{badarg,[{qlc,eval, [{error,qlc, {1,qlc,{used_generator_variable,'Wrapper'}}}, []]}, {mnesia_tm,apply_fun,3}, {mnesia_tm,execute_transaction,5}, {mnesia,wrap_trans,6}, {erl_eval,do_apply,5}, {shell,exprs,7}, {shell,eval_exprs,7}, {shell,eval_loop,3}]}} in function mnesia:wrap_trans/6 Now from everything I've read...I thought I'd be able to use the Wrapper variable later on in the query as a generator...thus allowing me to unpack things. Why would this be giving me an error? If I change it to: mnesia:activity(transaction, fun() -> qlc:eval(qlc:q([{A, B, C} || {A, B, C} <- mnesia:table(accounts)])) end, []). It works just fine and returns the record...and I can successfully match the pattern {A, B, C} with the account_wrapper record elsewhere. So what am I missing? Chris Hicks. _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions Ulf Wiger, CTO, Erlang Solutions, Ltd.http://erlang-solutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From vances@REDACTED Mon May 2 22:56:38 2011 From: vances@REDACTED (Vance Shipley) Date: Mon, 2 May 2011 16:56:38 -0400 Subject: [erlang-questions] supervisor:start_child In-Reply-To: <1424119010.1804752.1304367599050.JavaMail.apache@nm3.abv.bg> References: <1424119010.1804752.1304367599050.JavaMail.apache@nm3.abv.bg> Message-ID: <20110502205638.GH305@h216-235-12-168.host.egate.net> On Mon, May 02, 2011 at 11:19:59PM +0300, Martin Dimitrov wrote: } In our app we actually use the sup functions (delete_child and so on) } but we keep only the pids and since the relationship is one-to-one But really the relationship is not one to one but one to many, at least over time. Consider this: Start a supervisor with one child: 1> {ok, Sup} = supervisor:start_link(super, []). {ok,<0.33.0>} Start a new child: 2> Id = make_ref(). #Ref<0.0.0.32> 3> ChildSpec = {Id, {gen_server, start_link, [server, [], []]}, permanent, 4000, worker, [server]}. {#Ref<0.0.0.32>, {gen_server,start_link,[server,[],[]]}, permanent,4000,worker, [server]} 4> supervisor:start_child(Sup, ChildSpec). {ok,<0.38.0>} Now we have a process with pid() <0.38.0> created by the child specification: 5> Children = supervisor:which_children(Sup). [{#Ref<0.0.0.32>,<0.38.0>,worker,[server]}, {server,<0.34.0>,worker,[server]}] Now something tragic happens to that child: 6> {Id, Pid, _, _} = lists:keyfind(Id, 1, Children). {#Ref<0.0.0.32>,<0.38.0>,worker,[server]} 7> exit(Pid, oops). true That child specification is still identified by the unique reference however the process it is managing has changed to <0.42.0>: 8> supervisor:which_children(Sup). [{#Ref<0.0.0.32>,<0.42.0>,worker,[server]}, {server,<0.34.0>,worker,[server]}] } we retrieve the dynamic id. I thought that there might be an easier } way but from what I understand now there isn't. You either need to save the Id or dynamically learn it: 9> {Id, Pid, _, _} = lists:keyfind(Pid, 2, Children). {#Ref<0.0.0.32>,<0.38.0>,worker,[server]} I would add though that it is likely you really be considering using another supervision layer. Start a simple_one_for_one supervisor for each type of worker under the supervisor you are using now. -- -Vance From pmundkur.erlang@REDACTED Tue May 3 03:50:05 2011 From: pmundkur.erlang@REDACTED (Prashanth Mundkur) Date: Mon, 2 May 2011 18:50:05 -0700 Subject: [erlang-questions] Dialyzer questions Message-ID: We've recently been getting the upcoming release of Disco to go through the Dialyzer wringer, and it has been a very useful exercise. Thanks to Kostis' helpful wielding of the cluebat at the SF Erlang Factory! We are trying to understand the following output (I hope the inline code pasting below comes out readable): $ cat dial.erl -module(dial). -export([abort/2, extract/2, diskspace/1, monitor_diskspace/2, refresh_tags/1, monitor_launch/0]). % We have helper functions like this: abort(Msg, Code) -> error_logger:warning_report(Msg), exit(Code). % which give rise to the following dialyzer message: % % Function abort/2 only terminates with explicit exception % How do we interpret this message? % Even with a plt that includes stdlib, there is no warning for the % following code: -spec extract(binary(), nonempty_string()) -> 'ok'. extract(Pack, Dir) -> case zip:extract(Pack, [{cwd, Dir}]) of {ok, Files} -> Files; {error, Reason} -> exit({error, Reason}) end. % Here, the spawn_link of monitor_diskspace in monitor_launch() gives: % The created fun has no local return % whereas the spawn_link of refresh_tags doesn't. If the spawn_link % of monitor_diskspace() function is commented out, there is no % warning. It's not clear how to interpret the warning or the % inconsistency. % % Converting the nested list comprehension in monitor_diskspace into a % list:map made the warning go away, at the expense of readability and % perhaps even efficiency. -type diskinfo() :: {non_neg_integer(), non_neg_integer()}. -spec diskspace(nonempty_string()) -> {'ok', diskinfo()} | {'error', term()}. diskspace(Path) -> case Path of "a" -> {ok, {0,0}}; _ -> {error, error} end. -spec monitor_diskspace(nonempty_string(), [{diskinfo(), nonempty_string()}]) -> no_return(). monitor_diskspace(Root, Vols) -> Df = fun(VolName) -> diskspace(filename:join([Root, VolName])) end, NewVols = [{Space, VolName} || {VolName, {ok, Space}} <- [{VolName, Df(VolName)} || {_OldSpace, VolName} <- Vols]], monitor_diskspace(Root, NewVols). -spec refresh_tags(nonempty_string()) -> no_return(). refresh_tags(Root) -> {ok, _} = diskspace(Root), refresh_tags(Root). monitor_launch() -> spawn_link(fun() -> refresh_tags("abc") end), spawn_link(fun() -> monitor_diskspace("root", [{{0,0}, "a"}]) end). $ dialyzer --get_warnings -Wunmatched_returns -Werror_handling dial.erl Checking whether the PLT /home/mundkur/.dialyzer_plt is up-to-date... yes Proceeding with analysis... dial.erl:6: Function abort/2 only terminates with explicit exception dial.erl:66: The created fun has no local return $ dialyzer -v Dialyzer version v2.4.0 $ erl Erlang R14B01 (erts-5.8.2) [source] [64-bit] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false] -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Tue May 3 04:23:55 2011 From: ok@REDACTED (Richard O'Keefe) Date: Tue, 3 May 2011 14:23:55 +1200 Subject: [erlang-questions] byte() vs. char() use in documentation In-Reply-To: References: <20110502091415.GA6512@erix.ericsson.se> <372726991.139721304328918708.JavaMail.root@zimbra> <20110502095824.GA9576@erix.ericsson.se> <4DBE83B4.50501@cs.ntua.gr> Message-ID: <1424A262-399A-4045-9862-4316CCC9655E@cs.otago.ac.nz> On 3/05/2011, at 7:43 AM, James Churchman wrote: > strings can be of utf8 utf16 or utf32, No. The model for strings is "one list element = one unicode character", and both UTF-8 and UTF-16 violate that. A list of ASCII code-points is both a (Unicode) string and an iolist. Of course, nothing stops you holding an abstract string as a list of octets using UTF-8 (or for that matter, UTF-EBCDIC) or as a list of 16-bit units using UTF-16. It's just that if you do so, what you have doesn't count as an Erlang string any more (outside ASCII). > also there does seem to be a needed distinction between char() and byte() as they are not the same at all, but the documentation is wrong as at the moment iolists can infact only contain byte() not char() yes. From nick@REDACTED Tue May 3 09:44:51 2011 From: nick@REDACTED (Niclas Eklund) Date: Tue, 3 May 2011 09:44:51 +0200 Subject: [erlang-questions] erlang-bugs reports not showing in list In-Reply-To: <0FC1E82D-91D3-4ADA-BAA5-F7A805DD30EB@duomark.com> References: <0FC1E82D-91D3-4ADA-BAA5-F7A805DD30EB@duomark.com> Message-ID: Hello! The answer is yes. http://www.erlang.org/static/doc/mailinglist.html "You have to be a member to post. This reduces spam to a tolerable level. You can subscribe for every post, digest of posts or no-mail subscribtion to be able to post but read some other way e.g the archives or maybe Google Groups." Best Regards, Niclas @ Erlang/OTP On Mon, 2 May 2011, Jay Nelson wrote: > I am not registered as an individual to be a member of erlang-bugs, but > I have sent 2 emails in the last month (March re: reltool and rebar, > today re: dialyzer and binary:compile/1) that have not shown up on the > list. Are they automatically dropped by the email management system if > you are not a member of the list? > > jay > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From mrtndimitrov@REDACTED Tue May 3 10:02:35 2011 From: mrtndimitrov@REDACTED (Martin) Date: Tue, 3 May 2011 01:02:35 -0700 (PDT) Subject: [erlang-questions] Supervisor behaviour Message-ID: Hi, We have a supervisor with restrat strategy one_for_all, several permanent children and several temporal ones. When a permanent child crashes it is restrated which is absolutely desirable but the temporal children are also restrated. I expected the temporal children to be terminated but not started again. Is there something I am missing? Is this the normal behaviour? Regards, Martin From erlang@REDACTED Tue May 3 10:04:34 2011 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 3 May 2011 10:04:34 +0200 Subject: [erlang-questions] Best practices for distributing an application over erlang? In-Reply-To: <4D5B5967.9090102@gmail.com> References: <4D5B5967.9090102@gmail.com> Message-ID: On Wed, Feb 16, 2011 at 5:58 AM, Gregory Haskins wrote: > Hi All, > > I have been struggling trying to wrap my head around what might be the > best-practice for distributing a clustered erlang-application to a > plurality of erlang nodes, and keeping the cluster up to date from a > central location. > > Ideally, the subordinate erlang nodes that have just-enough logic to > connect to one another (e.g. cookies, ssl-keys, gossip-controller > addresses, etc are pre-distributed) but otherwise no specific > personality is known apriori. I can then implement some kind of central > service to remotely load/run a specific application (and any of its > dependencies). IOW: This is really about bootstrap for the time being > (e.g. Hot update is nice, but not a short term requirement at the > moment). The right conceptual vehicle for the payload would be a > standard erlang-release. > > So I have given this a lot of thought and read a ton of the books/doc on > the various options here. For instance, I have seen Joe Armstrong's > examples of sending a lambda down as payload in a message, using > dist_ac, boot-server, release_handler, etc. Every solution seems to > present its own set of problems/limitations, so I am unclear as to what > might be my best option here. > Oh dear - confusion reigns. There is a fundamental problem - no two distributed systems have the same requirements as regards fault-tolerance, behavior under load, latency, scalability etc. there are just two many variables. So what do we do in practice? - one common solution is the BFI (Brute force and Ignorance) solution. Assume a system of K physically separated nodes. K being say 5..25 (this is all very hand waving for K < 5 a different approach is probably needed) - for K < 1000 (ish) then full replication of all the code on a local file system is perfectly feasible. Forget everything about hot code upgrades etc. Simple take an entire node out of service, change all the code on the node, put it back into service. This implies that you implement some kind of data exchange protocol to get all the active data you need from a node before closing it down and to restore the data before you restart it. This is for planned outages - you can actually do this pretty quickly so it's not so bad - if it takes more than a few seconds then look at your algorithms, something is wrong. For non-planned outages (crashes) your design should put the system into a stable state and try to recover. You can of course, make things far more fine grained than this, using load_binary() etc. In my experience is used in development to get a quick turn-round times when developing. It's very convenient to just throw new code at the system to see what will happen, but this is very different to a planned roll-out of new code in a production system. I think you need to think about "what code replacement do I need in development" (my suggestion would be to just slurp new code over without worrying, if it crashes who cares, restart everything) and "how do I upgrade the code in a production system" (with great care node-at-a-time round-robbin fashion). It occurs to me that there is a good opportunity here for a complete framework to support common generic cases - ie think "gen_cluster" rather than gen_supervisor/server. I have seen such beasts but they have a heck of a lot more callbacks than gen_server :-) > > For instance, sending functions as payload only seems to work as long as > that function only invokes modules that already loaded/available on the > remote node. I can, of course, ensure that all required modules are > loaded on the remote node using things like code:load_binary(), but this > would mean I would need to a) figure out what modules are needed as part > of the release I want to distribute, and b) manually load each and every > module to the remote node, right? > > Well manually isn't so bad - a program does if for you - Its just a matter of sending a few Kbytes .. MBytes down a wire, hardly worth optimising ... > As far as dist_ac, this seems to be more geared towards creating > active/standby replicas of an app, rather than a process-peer model, so > that's out. > > boot-server is getting warmer, though I really want my grid to use > SSL-mutualauth + cookies, and I am not sure if the erl_prim_loader can > work over SSL inets. > > release_handler is getting warmer, though I still need to address the > bootstrap problem (either pre-load the initial release or use the > erl_prim_loader, as above). The other problem here is its focus is > really on hot-update, and at this juncture I really only care about > remote-update (e.g. cold restart is probably ok for now). > > > One solution I thought of is a play on the boot-server model, where I > can have one erlang application that connects in whatever ssl/cookie > protocol I want, contacts the service, downloads the release.tar.gz, and > then fires up a new beam instance with the release...hot updates, if > desired, could just use standard release-handler calls direct to the > subordinate vm. The problem with this solution is then I get into "well > how do I keep my loader-app up to date?" and my head explodes in a > circular reference ;). > Why not just have one simple roll-your-own boot-loader that you *never* change. If you make it very simple you'll never have to change it. There are bits of the system you can change later and bits you cannot change later. Make you mind up. Remember that what you can and cannot change at run-time is a design decision. Just make you mind up and don't change it. Your brain will go into a loop if you start thinking about how to change the boot loader which you had previously decided that by design "could not be changed". This is a common mistake in system design - first you say "X is fixed" you design the system with this in mind. Some person says "what happens if we change X" and you brain goes into a loop - "correct answer - we can't X is fixed" Having fix points in a design make life really really easy Decide that "I will never change the boot loader" and write your own boot loader so that you completely understand it and never change it - think of it as hardware. I've given an example below > > Long story short(er): I suspect I am just making all of this harder > than it needs to be, and there must be a ton of you who are just doing > similar operations all the time. Any help/pointers/guidance/suggestions > appreciated. > > It's actually not that difficult. You need to be able to remote stop a system send a file to the stopped system, restart the the stopped system all in a controlled manner. I did this on planet lab a few years ago. I made a simple socket server with a layer of encryption. the bootstrap opened a single port and listened a term-to-binary encoded message. Something like: (this the boot loader - never change it - it is so simple you will never have to change it) boot(Socket) -> receive {tcp, Socket, Bin} -> {M,F,A} = binary_to_term(Bin), apply(M,F,A), boot(Socket); end Then I send tuples like {file,write_file,[<>]}, etc. to the remote nodes from a single master node. You can just ping the remote nodes or keep a socket open to detect failure. You don't have to use *any* of the release stuff nor the kernel distribution stuff if you don't want to. /Joe > Kind Regards, > -Greg > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rtrlists@REDACTED Tue May 3 10:11:26 2011 From: rtrlists@REDACTED (Robert Raschke) Date: Tue, 3 May 2011 09:11:26 +0100 Subject: [erlang-questions] Looking for RDBMS driver with Transaction Support. In-Reply-To: References: Message-ID: Just to reiterate Ulf's point, in case you missed it. The standard Erlang odbc module supports transactions when you odbc:connect/2 using the option {auto_commit, off}. Although, if I remember correctly, nested txns are not supported. Robby On Mon, May 2, 2011 at 8:18 PM, Alex Arnon wrote: > Thank you all for the solutions, this is very helpful! > We will evaluate the epgsql and erlang-mysql solutions. > > > > On Mon, May 2, 2011 at 9:43 PM, Parnell Springmeyer wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> https://github.com/dizzyd/erlang-mysql-driver >> >> Look at the tests to see how transactions are used. I use them >> extensively in my current project. >> >> Alex Arnon writes: >> >> > Hi All, >> > >> > Is there an RDBMS driver in the Erlang universe whose API supports >> > transactions? >> > The docs for odbc, epgsql and emysql do not specify any kind of >> > transaction support. >> > >> > Thanks in advance! >> > >> > _______________________________________________ >> > erlang-questions mailing list >> > erlang-questions@REDACTED >> > http://erlang.org/mailman/listinfo/erlang-questions >> >> - -- >> Parnell "ixmatus" Springmeyer (http://ixmat.us) >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG/MacGPG2 v2.0.17 (Darwin) >> Comment: GPGTools - http://gpgtools.org >> >> iQEcBAEBAgAGBQJNvvs7AAoJEPvtlbpI1POLvQcH/jyrjTekFE3P0FeF6dn84ROo >> mAQQWI0cKGM8gLJOJA0kzaf3kEOZ4Ad6qBot2cXU1W5jWBDxRdf0DcvlsGCXx7uN >> fNOfLCug6/3NNICkCjTUu+mtE1zs3itxj4LU87fbNe9h65MelASwQh7NnXob11A2 >> 5ylQBXgzEdv6AaPavdO/ej9qRNDA0QieVTFaECW0Pzaly87q9XkBqkgQqoFt34Ta >> eAbewn90VhuQKB1GZZJDUOH58l57H2RaMKUqSqYMCCmqxwXXAmNUKyNYOsurx7za >> gCjSEBZ7JvCb+3yyLj6SWlHgTFypYNtZK+861lNLd8i2aKPsOuWHIo/9pkprO94= >> =PPX8 >> -----END PGP SIGNATURE----- >> > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrtndimitrov@REDACTED Tue May 3 10:22:41 2011 From: mrtndimitrov@REDACTED (Martin) Date: Tue, 3 May 2011 01:22:41 -0700 (PDT) Subject: [erlang-questions] Supervisor behaviour In-Reply-To: References: Message-ID: <7f7a247b-98eb-4cff-9eb2-f7310445d467@z37g2000vbl.googlegroups.com> And one more thing: When the supervisor restrart strategy is one_for_all and a process with specification type temporary crashes, the other processes are not terminated (and restrarted if with type permanent). Why is that? From attila.r.nohl@REDACTED Tue May 3 11:02:01 2011 From: attila.r.nohl@REDACTED (Attila Rajmund Nohl) Date: Tue, 3 May 2011 11:02:01 +0200 Subject: [erlang-questions] Dialyzer questions In-Reply-To: References: Message-ID: 2011/5/3, Prashanth Mundkur : [...] > We are trying to understand the following output (I hope the inline code > pasting below comes out readable): > > $ cat dial.erl > -module(dial). > -export([abort/2, extract/2, > diskspace/1, monitor_diskspace/2, refresh_tags/1, > monitor_launch/0]). > > % We have helper functions like this: > abort(Msg, Code) -> > error_logger:warning_report(Msg), > exit(Code). > % which give rise to the following dialyzer message: > % > % Function abort/2 only terminates with explicit exception > % How do we interpret this message? As it is written :-) The exit/1 call terminates the process, so the function does not return. If this is what you want, you can skip this warning. > % Even with a plt that includes stdlib, there is no warning for the > % following code: > -spec extract(binary(), nonempty_string()) -> 'ok'. > extract(Pack, Dir) -> > case zip:extract(Pack, [{cwd, Dir}]) of > {ok, Files} -> > Files; > {error, Reason} -> > exit({error, Reason}) > end. Yes, because at least one clause does return a value. From qqshfox@REDACTED Tue May 3 11:03:15 2011 From: qqshfox@REDACTED (Hanfei Shen) Date: Tue, 3 May 2011 17:03:15 +0800 Subject: [erlang-questions] Erlang and MySQL: ODBC, Column type not supported In-Reply-To: References: <4DBE7B49.1080505@erix.ericsson.se> Message-ID: Hi, I had set up a fresh system and reproduce this problem successfully. Here is something about my installations: vm: VirtualBox 4.0.6 r71416 gentoo: livecd: install-amd64-minimal-20110317.iso stage: stage3-amd64-20110428.tar.bz2 portage: portage-20110424.tar.bz2 I only installed: dev-db/mysql-5.1.51 dev-db/myodbc-5.1.6 dev-lang/erlang-13.2.4 USE="kpoll odbc smp" table schema: CREATE TABLE `action` ( `id` int(11) NOT NULL AUTO_INCREMENT, `code` varchar(255) NOT NULL, `compliment_desc` varchar(255) NOT NULL DEFAULT '', `status_desc` varchar(255) NOT NULL DEFAULT '', `parameter` varchar(255) NOT NULL DEFAULT '', `cause` varchar(255) NOT NULL DEFAULT '', `disabled` tinyint(1) NOT NULL DEFAULT '0', PRIMARY KEY (`id`), UNIQUE KEY `index_action_on_cause` (`cause`) ) ENGINE=InnoDB AUTO_INCREMENT=56 DEFAULT CHARSET=utf8; I see you are running on a 64 bit platform, maybe you can try it also on a > 32 bit platform. Maybe > you could try accessing the database from windows using the windows my-sql > driver. > I reproduced the problem on a 32bit server just right now... I'll try it on a windows machine asap. 2011/5/3 Hanfei Shen : > Hi, > > Hmmmmmm... The unixODBC is already in my system, but I don't know how > to use it... > > I will setup a vm with fresh system tomorrow to reproduce the problem... > > PS, could you figure out a name of ANOTHER ODBC-DRIVER which you mentioned? > > 2011/5/3 Hanfei Shen : >> Hi, >> >> I've tried https://github.com/dizzyd/erlang-mysql-driver, it works. >> >> I'm installing unixodbc... Wait a minute. Thnx... >> >> >> 2011/5/3 Ingela Andin : >>> Hi! >>> >>> Well the best thing would be if you can provide me with a way to reproduce it. >>> Do you have the possibility to try another odbc-driver with your database? >>> >>> Regards Ingela Erlang/OTP team - Ericsson AB >>> >>> >>> 2011/5/2 Hanfei Shen : >>>> Hi, >>>> >>>> I had changed the type from SQLINTEGER to SQLSMALLINT, but the problem >>>> is still there... >>>> >>>> (gdb) i func encode_data_type >>>> File odbcserver.c: >>>> static void encode_data_type(SQLSMALLINT, SQLINTEGER, SQLSMALLINT, db_state *); >>>> >>>> Breakpoint 1, encode_data_type (sql_type=-9, size=255, >>>> decimal_digits=0, state=0x7fffa5380210) at odbcserver.c:1396 >>>> 1396 switch(sql_type) { >>>> >>>> Do you need any details? >>>> >>>> 2011/5/2 Ingela Anderton Andin : >>>>> Hi! >>>>> >>>>> Hanfei Shen wrote: >>>>>> >>>>>> Hi Ingela, >>>>>> >>>>>> Did you mean the value of variable "sql_type"? >>>>>> >>>>>> >>>>> >>>>> Yes. >>>>> >>>>>> I tried to inspect it through gdb, setting a break on func >>>>>> encode_data_type. And then I got: >>>>>> >>>>>> Breakpoint 1, encode_data_type (sql_type=-9, size=255, >>>>>> decimal_digits=0, state=0x7fffc657ec40) at odbcserver.c:1396 >>>>>> 1396 switch(sql_type) { >>>>>> >>>>>> >>>>> >>>>> Well that is defenetly not a good value. Looking at the code just now >>>>> I noticed that >>>>> >>>>> encode_data_type defines sql_type as "SQLINTEGER sql_type" and it >>>>> ought to be "SQLSMALLINT sql_type". If you change that does it fix your >>>>> problem? >>>>> >>>>> Regards Ingela Erlang/OTP team - Ericsson AB >>>>> >>>>> >>>>> >>>>>> 2011/5/2 Ingela Andin : >>>>>> >>>>>>> >>>>>>> Hi! >>>>>>> >>>>>>> The erlang odbc application supports {sql-varchars, N} where N = 255 >>>>>>> in your case. The return values >>>>>>> you get suggest that the odbc-driver you have returns an unexpected >>>>>>> column type. >>>>>>> >>>>>>> In the erlang odbc port program there is a switch that handles type >>>>>>> when describing a coloumn that if we take out >>>>>>> the handling code looks like this. >>>>>>> >>>>>>> switch(sql_type) { >>>>>>> case SQL_CHAR: >>>>>>> case SQL_VARCHAR: >>>>>>> case SQL_WCHAR: >>>>>>> case SQL_WVARCHAR: >>>>>>> case SQL_NUMERIC: >>>>>>> case SQL_DECIMAL: >>>>>>> case SQL_INTEGER: >>>>>>> case SQL_TINYINT: >>>>>>> case SQL_SMALLINT: >>>>>>> case SQL_REAL: >>>>>>> case SQL_FLOAT: >>>>>>> case SQL_DOUBLE: >>>>>>> case SQL_BIT: >>>>>>> case SQL_TYPE_DATE: >>>>>>> case SQL_TYPE_TIME: >>>>>>> case SQL_TYPE_TIMESTAMP: >>>>>>> case SQL_BIGINT: >>>>>>> case SQL_BINARY: >>>>>>> case SQL_LONGVARCHAR: >>>>>>> case SQL_VARBINARY: >>>>>>> case SQL_LONGVARBINARY: >>>>>>> case SQL_INTERVAL_MONTH: >>>>>>> case SQL_INTERVAL_YEAR: >>>>>>> case SQL_INTERVAL_DAY: >>>>>>> case SQL_INTERVAL_MINUTE: >>>>>>> case SQL_INTERVAL_HOUR_TO_SECOND: >>>>>>> case SQL_INTERVAL_MINUTE_TO_SECOND: >>>>>>> case SQL_UNKNOWN_TYPE: >>>>>>> default: /* Will probably never happen */ >>>>>>> ei_x_encode_atom(&dynamic_buffer(state), "ODBC_UNSUPPORTED_TYPE"); >>>>>>> break; >>>>>>> } >>>>>>> >>>>>>> >>>>>>> And you end up in the default clause which is very unexpected and the >>>>>>> root to your problem. If you can figur out >>>>>>> what your driver returns for the ODBC C-API function SQLDescribeCol we >>>>>>> could know if the driver is at fault or if the odbc-port program is. >>>>>>> >>>>>>> Regards Ingela Erlang/OTP team - Ericsson AB >>>>>>> >>>>>>> 2011/5/1 Hanfei Shen : >>>>>>> >>>>>>>> >>>>>>>> Dear all, >>>>>>>> >>>>>>>> I'm a newbie programming in erlang. When I used ODBC to connect to a >>>>>>>> MySQL database through Connector/ODBC (MyODBC), I got some error when >>>>>>>> calling odbc:sql_query(Conn, "SELECT * FROM action"): >>>>>>>> >>>>>>>> {error,"Column type not supported"} >>>>>>>> >>>>>>>> Then I call odbc:describe_table(Conn, "action"), it returned: >>>>>>>> >>>>>>>> {ok,[{"id",sql_integer}, >>>>>>>> {"code",'ODBC_UNSUPPORTED_TYPE'}, >>>>>>>> {"compliment_desc",'ODBC_UNSUPPORTED_TYPE'}, >>>>>>>> {"status_desc",'ODBC_UNSUPPORTED_TYPE'}, >>>>>>>> {"parameter",'ODBC_UNSUPPORTED_TYPE'}, >>>>>>>> {"cause",'ODBC_UNSUPPORTED_TYPE'}, >>>>>>>> {"disabled",sql_tinyint}]} >>>>>>>> >>>>>>>> And desc the table in mysql client: >>>>>>>> mysql> desc action; >>>>>>>> >>>>>>>> +-----------------+--------------+------+-----+---------+----------------+ >>>>>>>> | Field | Type | Null | Key | Default | Extra >>>>>>>> | >>>>>>>> >>>>>>>> +-----------------+--------------+------+-----+---------+----------------+ >>>>>>>> | id | int(11) | NO | PRI | NULL | auto_increment >>>>>>>> | >>>>>>>> | code | varchar(255) | NO | | NULL | >>>>>>>> | >>>>>>>> | compliment_desc | varchar(255) | NO | | | >>>>>>>> | >>>>>>>> | status_desc | varchar(255) | NO | | | >>>>>>>> | >>>>>>>> | parameter | varchar(255) | NO | | | >>>>>>>> | >>>>>>>> | cause | varchar(255) | NO | UNI | | >>>>>>>> | >>>>>>>> | disabled | tinyint(1) | NO | | 0 | >>>>>>>> | >>>>>>>> >>>>>>>> +-----------------+--------------+------+-----+---------+----------------+ >>>>>>>> >>>>>>>> It seems that Erlang ODBC driver does not support the mysql type >>>>>>>> varchar? How can I use the database without touching the db schema? >>>>>>>> >>>>>>>> >>>>>>>> Some details about the system env: >>>>>>>> >>>>>>>> $ uname -a >>>>>>>> Linux 2.6.36-gentoo-r8 #4 SMP Thu Apr 7 20:13:18 CST 2011 x86_64 >>>>>>>> Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz GenuineIntel GNU/Linux >>>>>>>> >>>>>>>> $ erl >>>>>>>> Erlang R13B04 (erts-5.7.5) [source] [64-bit] [smp:2:2] [rq:2] >>>>>>>> [async-threads:0] [kernel-poll:false] >>>>>>>> >>>>>>>> $ emerge -vp erlang >>>>>>>> dev-lang/erlang-13.2.4 USE="doc kpoll odbc smp ssl -emacs -hipe -java >>>>>>>> -sctp -tk -wxwidgets" >>>>>>>> >>>>>>>> eshell> code:which(odbc). >>>>>>>> "/usr/lib64/erlang/lib/odbc-2.10.7/ebin/odbc.beam" >>>>>>>> >>>>>>>> $ mysql -V >>>>>>>> mysql Ver 14.14 Distrib 5.1.51, for pc-linux-gnu (x86_64) using >>>>>>>> readline 5.1 >>>>>>>> >>>>>>>> Server version: 5.1.51-log Gentoo Linux mysql-5.1.51 >>>>>>>> >>>>>>>> $ emerge -vp myodbc >>>>>>>> dev-db/myodbc-5.1.6 USE="-debug -doc -qt4 -static" >>>>>>>> >>>>>>>> >>>>>>>> Any help will be greatly appreciated. Thanks in advance. >>>>>>>> Sorry for my poor English, I'm not a native... >>>>>>>> >>>>>>>> Best, >>>>>>>> >>>>>>>> -- >>>>>>>> Hanfei >>>>>>>> _______________________________________________ >>>>>>>> erlang-questions mailing list >>>>>>>> erlang-questions@REDACTED >>>>>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan@REDACTED Tue May 3 11:04:39 2011 From: ivan@REDACTED (Ivan Uemlianin) Date: Tue, 03 May 2011 10:04:39 +0100 Subject: [erlang-questions] removing an element from a list Message-ID: <4DBFC527.7010505@llaisdy.com> Dear All It seems there are two ways to remove an element from a list: 1> A = [q,w,e,r,t,y]. [q,w,e,r,t,y] 2> A -- [q]. [w,e,r,t,y] 3> lists:delete(q, A). [w,e,r,t,y] 4> Which is better, and why, or is TMTOWTDI? (I'm sure the answer won't be as simple as the question:). With thanks and best wishes Ivan -- ============================================================ Ivan A. Uemlianin Speech Technology Research and Development ivan@REDACTED www.llaisdy.com llaisdy.wordpress.com www.linkedin.com/in/ivanuemlianin "Froh, froh! Wie seine Sonnen, seine Sonnen fliegen" (Schiller, Beethoven) ============================================================ From mazen.harake@REDACTED Tue May 3 11:15:23 2011 From: mazen.harake@REDACTED (Mazen Harake) Date: Tue, 3 May 2011 11:15:23 +0200 Subject: [erlang-questions] removing an element from a list In-Reply-To: <4DBFC527.7010505@llaisdy.com> References: <4DBFC527.7010505@llaisdy.com> Message-ID: They are equally "good". A -- [q] says "remove all occurrences found in the right list from the left list". This is sugar syntax for lists:subtract/2. A -- [q,w] would produce [e,r,t,y]. lists:delete(q, A) says remote element q from list A (note: only one element). The simple answer is: They are almost the same. if you only want to remove 1 element the list then use delete, if you want to remove several then use subtract. note: both functions only remove the first occurrence of the element, E.g. [a,a,b,c] -- [a] will result in [a,b,c] and _not_ [b, c], same behaviour for delete. /M On 3 May 2011 11:04, Ivan Uemlianin wrote: > Dear All > > It seems there are two ways to remove an element from a list: > > 1> A = [q,w,e,r,t,y]. > [q,w,e,r,t,y] > 2> A -- [q]. > [w,e,r,t,y] > 3> lists:delete(q, A). > [w,e,r,t,y] > 4> > > > Which is better, and why, or is TMTOWTDI? (I'm sure the answer won't be as > simple as the question:). > > With thanks and best wishes > > Ivan > > -- > ============================================================ > Ivan A. Uemlianin > Speech Technology Research and Development > > ivan@REDACTED > www.llaisdy.com > llaisdy.wordpress.com > www.linkedin.com/in/ivanuemlianin > > "Froh, froh! Wie seine Sonnen, seine Sonnen fliegen" > (Schiller, Beethoven) > ============================================================ > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From spawn.think@REDACTED Tue May 3 11:26:39 2011 From: spawn.think@REDACTED (Ahmed Omar) Date: Tue, 3 May 2011 11:26:39 +0200 Subject: [erlang-questions] removing an element from a list In-Reply-To: References: <4DBFC527.7010505@llaisdy.com> Message-ID: * 2nd case (removing several elements, i.e subtracting lists) you need to be careful, if your lists are huge you wanna consider using sets http://www.erlang.org/doc/efficiency_guide/commoncaveats.html#id59266 On Tue, May 3, 2011 at 11:15 AM, Mazen Harake wrote: > The simple answer is: They are almost the same. if you only want to remove > 1 element the list then use delete, if you want to remove several then use > subtract. -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan@REDACTED Tue May 3 11:27:56 2011 From: ivan@REDACTED (Ivan Uemlianin) Date: Tue, 03 May 2011 10:27:56 +0100 Subject: [erlang-questions] removing an element from a list In-Reply-To: References: <4DBFC527.7010505@llaisdy.com> Message-ID: <4DBFCA9C.1060502@llaisdy.com> Thanks! I think I might switch to the longhand version for readability (not to mention I've been subtracting all this time when I should have been deleting). Ivan On 03/05/2011 10:15, Mazen Harake wrote: > They are equally "good". > > A -- [q] says "remove all occurrences found in the right list from the > left list". This is sugar syntax for lists:subtract/2. A -- [q,w] > would produce [e,r,t,y]. > lists:delete(q, A) says remote element q from list A (note: only one > element). > > The simple answer is: They are almost the same. if you only want to > remove 1 element the list then use delete, if you want to remove > several then use subtract. > > note: both functions only remove the first occurrence of the element, > E.g. [a,a,b,c] -- [a] will result in [a,b,c] and _not_ [b, c], same > behaviour for delete. > > /M > > On 3 May 2011 11:04, Ivan Uemlianin > wrote: > > Dear All > > It seems there are two ways to remove an element from a list: > > 1> A = [q,w,e,r,t,y]. > [q,w,e,r,t,y] > 2> A -- [q]. > [w,e,r,t,y] > 3> lists:delete(q, A). > [w,e,r,t,y] > 4> > > > Which is better, and why, or is TMTOWTDI? (I'm sure the answer > won't be as simple as the question:). > > With thanks and best wishes > > Ivan > > -- > ============================================================ > Ivan A. Uemlianin > Speech Technology Research and Development > > ivan@REDACTED > www.llaisdy.com > llaisdy.wordpress.com > www.linkedin.com/in/ivanuemlianin > > > "Froh, froh! Wie seine Sonnen, seine Sonnen fliegen" > (Schiller, Beethoven) > ============================================================ > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- ============================================================ Ivan A. Uemlianin Speech Technology Research and Development ivan@REDACTED www.llaisdy.com llaisdy.wordpress.com www.linkedin.com/in/ivanuemlianin "Froh, froh! Wie seine Sonnen, seine Sonnen fliegen" (Schiller, Beethoven) ============================================================ From ivan@REDACTED Tue May 3 11:30:52 2011 From: ivan@REDACTED (Ivan Uemlianin) Date: Tue, 03 May 2011 10:30:52 +0100 Subject: [erlang-questions] removing an element from a list In-Reply-To: References: <4DBFC527.7010505@llaisdy.com> Message-ID: <4DBFCB4C.4040708@llaisdy.com> Thanks, that was going to be my second question. I was thinking some of the lists I'm using should probably be dicts, ... or sets. Best Ivan On 03/05/2011 10:26, Ahmed Omar wrote: > * 2nd case (removing several elements, i.e subtracting lists) you need > to be careful, if your lists are huge you wanna consider using sets > http://www.erlang.org/doc/efficiency_guide/commoncaveats.html#id59266 > > On Tue, May 3, 2011 at 11:15 AM, Mazen Harake > wrote: > > The simple answer is: They are almost the same. if you only want > to remove 1 element the list then use delete, if you want to > remove several then use subtract. > > > > > -- > Best Regards, > - Ahmed Omar > http://nl.linkedin.com/in/adiaa > Follow me on twitter > @spawn_think > -- ============================================================ Ivan A. Uemlianin Speech Technology Research and Development ivan@REDACTED www.llaisdy.com llaisdy.wordpress.com www.linkedin.com/in/ivanuemlianin "Froh, froh! Wie seine Sonnen, seine Sonnen fliegen" (Schiller, Beethoven) ============================================================ From raimo+erlang-questions@REDACTED Tue May 3 11:45:49 2011 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Tue, 3 May 2011 11:45:49 +0200 Subject: [erlang-questions] byte() vs. char() use in documentation In-Reply-To: References: <20110502091415.GA6512@erix.ericsson.se> <372726991.139721304328918708.JavaMail.root@zimbra> <20110502095824.GA9576@erix.ericsson.se> <4DBE83B4.50501@cs.ntua.gr> Message-ID: <20110503094549.GA10981@erix.ericsson.se> On Mon, May 02, 2011 at 08:43:33PM +0100, James Churchman wrote: > So just for my own understanding, and as it seems extremely important ( > strings are quite important these days!), as it stands now: > > iolists cant can only ( officially?) contain utf8? ( as no utf8 code point > will exceed 255, like latin1 / asci, and are therefor are all byte() ) Richard O'Keefe explained this nicely, I'll just elaborate. iolists were when introduced for handling byte sequences, not having to copy but just building them in nested form, either from individual bytes or from binaries. Back then characters were only latin-1 hence matched bytes nicely and therefore iolists. This is no longer true. Now you will have to do a translation from a seqence of characters into the corresponding byte sequence in an iolist. The preferred representation in erlang is utf-8 since it is the default for e.g the unicode module and for the ~t modifier in the io module when printing strings > > strings can be of utf8 utf16 or utf32, but only the utf8 version is allowed The programmer should regard strings as a sequence of unicode code points. As such they are just that and there is no encoding to bother about. The code point number uniquely defines which unicode character it is. > in an iolist? ( and therefore if you wanted an "iolist" ( eg a non flat list UTF-8 is not the only encoding allowed in an iolist. You can do any encoding as you desire. If you use the unicode module the default format for encoding and decoding of binaries is utf8, but utf16 or utf32 big or little endian is easy to do. An iolist is just a sequence of bytes. > of chars) that contained utf 16 or 32 code points you would have to stick An iolist is a non-flat list of bytes. Do not mixup bytes with characters. > exclusively to lists ( strings) and not binaries and use lists:flatten You can not just use lists:flatten on a unicode character string to get an iolist. The Unicode code points > 255 are still there. You will have to encode the unicode characters into a suitable byte representation e.g using the unicode module. > before you finished with it, to remove all the nested lists ) > > binaries can be of any unicode type.. Binaries are sequences of bytes. Period. You decide what they mean. > > also there does seem to be a needed distinction between char() and byte() as > they are not the same at all, but the documentation is wrong as at the > moment iolists can infact only contain byte() not char() Yes. > > the suggested direction is to repair the docs so that they specify only > allowing 0~255 ints( byte() ) in iolists rather than allowing io-lists to > contain any string as they did before the introduction of unicode / in the > days of latin1 etc.. ? Yes. That iolists could contain any string was by accident since there were no characters > 255 in the days of latin1. Since iolists is about sequences of bytes they can not be fixed into being allowed to contain any character. For that to be possible you would have to define the byte encoding for iolists, or store the byte encoding with a particular iolist. Since there is so many byte encodings that are used it is better to make this visible to the programmer so he/she is forced to understand the byte encoding problem and to handle it explicitly. Therefore is iolists now as the always were secuences of bytes (8-bit). And that is all. > > > i think that that goes agents most ( even erlang implementers :-) ) opinion > of what an iolist is ( that being a list of any valid string or binary) but I think not. An iolist is any valid byte or binary sequence. Binaries are sequences of bytes. They are all about bytes. Characters and strings are today vastly more complex beasts than they were when US-ASCII and later ISO-LATIN-1 was the norm. This must be visible to the programmer. > maybe ( to raise a totally different problem) would prevent the possibility > of an iolist having a mixed unicode type and still begin "valid" ( even tho > i guess this is still possible as binaries can in fact be other utf > representations) I repeat again. The programmer decides what the bytes mean. The list [0,0,16#21,16#2b] e.g would mean "angstrom sign" if the encoding is UTF-32 big endian. And that is a valid iolist. But [16#212b] is not. > > > > On 2 May 2011 11:13, Kostis Sagonas wrote: > > > Raimo Niskanen wrote: > > > >> > >> This became messy when char() was re-defined from latin-1 character > >> to unicode character. That affected string() that affected iolist() > >> and the latter was incorrect. > >> > >> We must clean up the mess. > >> > > > > Right. The sooner it happens the better it is. > > > > ... Either by completing the notion of char() > >> > >> being unicode and hence rewriting iolist() to contain byte() and binary(), > >> or by reverting to char() being latin-1 char and using unicode:char() > >> and unicode:string() where that is correct... > >> > > > > Please, by all means do the former. The latter will only cause havoc > > everywhere. For starters, I do not see any need in having two different > > basic types (byte() and char()) denoting (pretty much) the same thing. The > > only thing this does is cause unnecessary confusion to newcomers (and > > apparently to some old-timers too). Second, if you choose the latter you > > will eventually have to change lots of type inference code, because I > > promise you I will not do this, and believe me you don't want to go there... > > (The Vietnam jungle is probably a friendlier place ;) ) > > > > Cheers, > > Kostis > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From qqshfox@REDACTED Tue May 3 12:09:36 2011 From: qqshfox@REDACTED (Hanfei Shen) Date: Tue, 3 May 2011 18:09:36 +0800 Subject: [erlang-questions] Erlang and MySQL: ODBC, Column type not supported In-Reply-To: References: <4DBE7B49.1080505@erix.ericsson.se> Message-ID: Hi, The same on my windows 7 32 bit workstation. Erlang R13B02 (erts-5.7.3) 4> code:which(odbc). "d:/PROGRA~1/ERL57~1.3/lib/odbc-2.10.5/ebin/odbc.beam" mysql odbc 5.1.8 I'm downloading the latest version of erlang (R14B02)... 2011/5/3 Hanfei Shen > Hi, > > I had set up a fresh system and reproduce this problem successfully. > Here is something about my installations: > > vm: > VirtualBox 4.0.6 r71416 > > gentoo: > livecd: install-amd64-minimal-20110317.iso > stage: stage3-amd64-20110428.tar.bz2 > portage: portage-20110424.tar.bz2 > > I only installed: > > dev-db/mysql-5.1.51 > > dev-db/myodbc-5.1.6 > dev-lang/erlang-13.2.4 USE="kpoll odbc smp" > > table schema: > > CREATE TABLE `action` ( > `id` int(11) NOT NULL AUTO_INCREMENT, > `code` varchar(255) NOT NULL, > `compliment_desc` varchar(255) NOT NULL DEFAULT '', > `status_desc` varchar(255) NOT NULL DEFAULT '', > `parameter` varchar(255) NOT NULL DEFAULT '', > `cause` varchar(255) NOT NULL DEFAULT '', > `disabled` tinyint(1) NOT NULL DEFAULT '0', > PRIMARY KEY (`id`), > UNIQUE KEY `index_action_on_cause` (`cause`) > ) ENGINE=InnoDB AUTO_INCREMENT=56 DEFAULT CHARSET=utf8; > > > > I see you are running on a 64 bit platform, maybe you can try it also on >> a 32 bit platform. Maybe >> you could try accessing the database from windows using the windows my-sql >> driver. >> > > I reproduced the problem on a 32bit server just right now... > > I'll try it on a windows machine asap. > > > 2011/5/3 Hanfei Shen : > > Hi, > > > > Hmmmmmm... The unixODBC is already in my system, but I don't know how > > to use it... > > > > I will setup a vm with fresh system tomorrow to reproduce the problem... > > > > PS, could you figure out a name of ANOTHER ODBC-DRIVER which you > mentioned? > > > > 2011/5/3 Hanfei Shen : > >> Hi, > >> > >> I've tried https://github.com/dizzyd/erlang-mysql-driver, it works. > >> > >> I'm installing unixodbc... Wait a minute. Thnx... > >> > >> > >> 2011/5/3 Ingela Andin : > >>> Hi! > >>> > >>> Well the best thing would be if you can provide me with a way to > reproduce it. > >>> Do you have the possibility to try another odbc-driver with your > database? > >>> > >>> Regards Ingela Erlang/OTP team - Ericsson AB > >>> > >>> > >>> 2011/5/2 Hanfei Shen : > >>>> Hi, > >>>> > >>>> I had changed the type from SQLINTEGER to SQLSMALLINT, but the problem > >>>> is still there... > >>>> > >>>> (gdb) i func encode_data_type > >>>> File odbcserver.c: > >>>> static void encode_data_type(SQLSMALLINT, SQLINTEGER, SQLSMALLINT, > db_state *); > >>>> > >>>> Breakpoint 1, encode_data_type (sql_type=-9, size=255, > >>>> decimal_digits=0, state=0x7fffa5380210) at odbcserver.c:1396 > >>>> 1396 switch(sql_type) { > >>>> > >>>> Do you need any details? > >>>> > >>>> 2011/5/2 Ingela Anderton Andin : > >>>>> Hi! > >>>>> > >>>>> Hanfei Shen wrote: > >>>>>> > >>>>>> Hi Ingela, > >>>>>> > >>>>>> Did you mean the value of variable "sql_type"? > >>>>>> > >>>>>> > >>>>> > >>>>> Yes. > >>>>> > >>>>>> I tried to inspect it through gdb, setting a break on func > >>>>>> encode_data_type. And then I got: > >>>>>> > >>>>>> Breakpoint 1, encode_data_type (sql_type=-9, size=255, > >>>>>> decimal_digits=0, state=0x7fffc657ec40) at odbcserver.c:1396 > >>>>>> 1396 switch(sql_type) { > >>>>>> > >>>>>> > >>>>> > >>>>> Well that is defenetly not a good value. Looking at the code just now > >>>>> I noticed that > >>>>> > >>>>> encode_data_type defines sql_type as "SQLINTEGER sql_type" and it > >>>>> ought to be "SQLSMALLINT sql_type". If you change that does it fix > your > >>>>> problem? > >>>>> > >>>>> Regards Ingela Erlang/OTP team - Ericsson AB > >>>>> > >>>>> > >>>>> > >>>>>> 2011/5/2 Ingela Andin : > >>>>>> > >>>>>>> > >>>>>>> Hi! > >>>>>>> > >>>>>>> The erlang odbc application supports {sql-varchars, N} where N = > 255 > >>>>>>> in your case. The return values > >>>>>>> you get suggest that the odbc-driver you have returns an unexpected > >>>>>>> column type. > >>>>>>> > >>>>>>> In the erlang odbc port program there is a switch that handles type > >>>>>>> when describing a coloumn that if we take out > >>>>>>> the handling code looks like this. > >>>>>>> > >>>>>>> switch(sql_type) { > >>>>>>> case SQL_CHAR: > >>>>>>> case SQL_VARCHAR: > >>>>>>> case SQL_WCHAR: > >>>>>>> case SQL_WVARCHAR: > >>>>>>> case SQL_NUMERIC: > >>>>>>> case SQL_DECIMAL: > >>>>>>> case SQL_INTEGER: > >>>>>>> case SQL_TINYINT: > >>>>>>> case SQL_SMALLINT: > >>>>>>> case SQL_REAL: > >>>>>>> case SQL_FLOAT: > >>>>>>> case SQL_DOUBLE: > >>>>>>> case SQL_BIT: > >>>>>>> case SQL_TYPE_DATE: > >>>>>>> case SQL_TYPE_TIME: > >>>>>>> case SQL_TYPE_TIMESTAMP: > >>>>>>> case SQL_BIGINT: > >>>>>>> case SQL_BINARY: > >>>>>>> case SQL_LONGVARCHAR: > >>>>>>> case SQL_VARBINARY: > >>>>>>> case SQL_LONGVARBINARY: > >>>>>>> case SQL_INTERVAL_MONTH: > >>>>>>> case SQL_INTERVAL_YEAR: > >>>>>>> case SQL_INTERVAL_DAY: > >>>>>>> case SQL_INTERVAL_MINUTE: > >>>>>>> case SQL_INTERVAL_HOUR_TO_SECOND: > >>>>>>> case SQL_INTERVAL_MINUTE_TO_SECOND: > >>>>>>> case SQL_UNKNOWN_TYPE: > >>>>>>> default: /* Will probably never happen */ > >>>>>>> ei_x_encode_atom(&dynamic_buffer(state), > "ODBC_UNSUPPORTED_TYPE"); > >>>>>>> break; > >>>>>>> } > >>>>>>> > >>>>>>> > >>>>>>> And you end up in the default clause which is very unexpected and > the > >>>>>>> root to your problem. If you can figur out > >>>>>>> what your driver returns for the ODBC C-API function SQLDescribeCol > we > >>>>>>> could know if the driver is at fault or if the odbc-port program > is. > >>>>>>> > >>>>>>> Regards Ingela Erlang/OTP team - Ericsson AB > >>>>>>> > >>>>>>> 2011/5/1 Hanfei Shen : > >>>>>>> > >>>>>>>> > >>>>>>>> Dear all, > >>>>>>>> > >>>>>>>> I'm a newbie programming in erlang. When I used ODBC to connect to > a > >>>>>>>> MySQL database through Connector/ODBC (MyODBC), I got some error > when > >>>>>>>> calling odbc:sql_query(Conn, "SELECT * FROM action"): > >>>>>>>> > >>>>>>>> {error,"Column type not supported"} > >>>>>>>> > >>>>>>>> Then I call odbc:describe_table(Conn, "action"), it returned: > >>>>>>>> > >>>>>>>> {ok,[{"id",sql_integer}, > >>>>>>>> {"code",'ODBC_UNSUPPORTED_TYPE'}, > >>>>>>>> {"compliment_desc",'ODBC_UNSUPPORTED_TYPE'}, > >>>>>>>> {"status_desc",'ODBC_UNSUPPORTED_TYPE'}, > >>>>>>>> {"parameter",'ODBC_UNSUPPORTED_TYPE'}, > >>>>>>>> {"cause",'ODBC_UNSUPPORTED_TYPE'}, > >>>>>>>> {"disabled",sql_tinyint}]} > >>>>>>>> > >>>>>>>> And desc the table in mysql client: > >>>>>>>> mysql> desc action; > >>>>>>>> > >>>>>>>> > +-----------------+--------------+------+-----+---------+----------------+ > >>>>>>>> | Field | Type | Null | Key | Default | Extra > >>>>>>>> | > >>>>>>>> > >>>>>>>> > +-----------------+--------------+------+-----+---------+----------------+ > >>>>>>>> | id | int(11) | NO | PRI | NULL | > auto_increment > >>>>>>>> | > >>>>>>>> | code | varchar(255) | NO | | NULL | > >>>>>>>> | > >>>>>>>> | compliment_desc | varchar(255) | NO | | | > >>>>>>>> | > >>>>>>>> | status_desc | varchar(255) | NO | | | > >>>>>>>> | > >>>>>>>> | parameter | varchar(255) | NO | | | > >>>>>>>> | > >>>>>>>> | cause | varchar(255) | NO | UNI | | > >>>>>>>> | > >>>>>>>> | disabled | tinyint(1) | NO | | 0 | > >>>>>>>> | > >>>>>>>> > >>>>>>>> > +-----------------+--------------+------+-----+---------+----------------+ > >>>>>>>> > >>>>>>>> It seems that Erlang ODBC driver does not support the mysql type > >>>>>>>> varchar? How can I use the database without touching the db > schema? > >>>>>>>> > >>>>>>>> > >>>>>>>> Some details about the system env: > >>>>>>>> > >>>>>>>> $ uname -a > >>>>>>>> Linux 2.6.36-gentoo-r8 #4 SMP Thu Apr 7 20:13:18 CST 2011 x86_64 > >>>>>>>> Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz GenuineIntel GNU/Linux > >>>>>>>> > >>>>>>>> $ erl > >>>>>>>> Erlang R13B04 (erts-5.7.5) [source] [64-bit] [smp:2:2] [rq:2] > >>>>>>>> [async-threads:0] [kernel-poll:false] > >>>>>>>> > >>>>>>>> $ emerge -vp erlang > >>>>>>>> dev-lang/erlang-13.2.4 USE="doc kpoll odbc smp ssl -emacs -hipe > -java > >>>>>>>> -sctp -tk -wxwidgets" > >>>>>>>> > >>>>>>>> eshell> code:which(odbc). > >>>>>>>> "/usr/lib64/erlang/lib/odbc-2.10.7/ebin/odbc.beam" > >>>>>>>> > >>>>>>>> $ mysql -V > >>>>>>>> mysql Ver 14.14 Distrib 5.1.51, for pc-linux-gnu (x86_64) using > >>>>>>>> readline 5.1 > >>>>>>>> > >>>>>>>> Server version: 5.1.51-log Gentoo Linux mysql-5.1.51 > >>>>>>>> > >>>>>>>> $ emerge -vp myodbc > >>>>>>>> dev-db/myodbc-5.1.6 USE="-debug -doc -qt4 -static" > >>>>>>>> > >>>>>>>> > >>>>>>>> Any help will be greatly appreciated. Thanks in advance. > >>>>>>>> Sorry for my poor English, I'm not a native... > >>>>>>>> > >>>>>>>> Best, > >>>>>>>> > >>>>>>>> -- > >>>>>>>> Hanfei > >>>>>>>> _______________________________________________ > >>>>>>>> erlang-questions mailing list > >>>>>>>> erlang-questions@REDACTED > >>>>>>>> http://erlang.org/mailman/listinfo/erlang-questions > >>>>>>>> > >>>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> _______________________________________________ > >>>> erlang-questions mailing list > >>>> erlang-questions@REDACTED > >>>> http://erlang.org/mailman/listinfo/erlang-questions > >>>> > >>> > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zambal@REDACTED Tue May 3 12:16:08 2011 From: zambal@REDACTED (zambal) Date: Tue, 3 May 2011 03:16:08 -0700 (PDT) Subject: [erlang-questions] removing an element from a list In-Reply-To: <4DBFC527.7010505@llaisdy.com> References: <4DBFC527.7010505@llaisdy.com> Message-ID: Maybe it's just this particular example, but if it's always the first element in a list that needs to be removed, this is probably the fasted: 1> A = [q,w,e,r,t,y]. [q,w,e,r,t,y] 2> [_|B] = A. [q,w,e,r,t,y] 3> B. [w,e,r,t,y] -- Vincent On May 3, 11:04?am, Ivan Uemlianin wrote: > Dear All > > It seems there are two ways to remove an element from a list: > > ? ? 1> A = [q,w,e,r,t,y]. > ? ? [q,w,e,r,t,y] > ? ? 2> A -- [q]. > ? ? [w,e,r,t,y] > ? ? 3> lists:delete(q, A). > ? ? [w,e,r,t,y] > ? ? 4> > > Which is better, and why, or is TMTOWTDI? ?(I'm sure the answer won't be > as simple as the question:). > > With thanks and best wishes > > Ivan > > -- > ============================================================ > Ivan A. Uemlianin > Speech Technology Research and Development > > ? ? ? ? ? ? ? ? ? ? ?i...@REDACTED > ? ? ? ? ? ? ? ? ? ? ?www.llaisdy.com > ? ? ? ? ? ? ? ? ? ? ? ? ? llaisdy.wordpress.com > ? ? ? ? ? ? ? ? ? ? ?www.linkedin.com/in/ivanuemlianin > > ? ? ?"Froh, froh! Wie seine Sonnen, seine Sonnen fliegen" > ? ? ? ? ? ? ? ? ? ? ? (Schiller, Beethoven) > ============================================================ > > _______________________________________________ > erlang-questions mailing list > erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions From qqshfox@REDACTED Tue May 3 13:11:36 2011 From: qqshfox@REDACTED (Hanfei Shen) Date: Tue, 3 May 2011 19:11:36 +0800 Subject: [erlang-questions] Erlang and MySQL: ODBC, Column type not supported In-Reply-To: References: <4DBE7B49.1080505@erix.ericsson.se> Message-ID: Hi, Well it works on R14B02... 2011/5/3 Hanfei Shen > Hi, > > The same on my windows 7 32 bit workstation. > > Erlang R13B02 (erts-5.7.3) > > 4> code:which(odbc). > "d:/PROGRA~1/ERL57~1.3/lib/odbc-2.10.5/ebin/odbc.beam" > > mysql odbc 5.1.8 > > > > I'm downloading the latest version of erlang (R14B02)... > > > > 2011/5/3 Hanfei Shen > >> Hi, >> >> I had set up a fresh system and reproduce this problem successfully. >> Here is something about my installations: >> >> vm: >> VirtualBox 4.0.6 r71416 >> >> gentoo: >> livecd: install-amd64-minimal-20110317.iso >> stage: stage3-amd64-20110428.tar.bz2 >> portage: portage-20110424.tar.bz2 >> >> I only installed: >> >> dev-db/mysql-5.1.51 >> >> dev-db/myodbc-5.1.6 >> dev-lang/erlang-13.2.4 USE="kpoll odbc smp" >> >> table schema: >> >> CREATE TABLE `action` ( >> `id` int(11) NOT NULL AUTO_INCREMENT, >> `code` varchar(255) NOT NULL, >> `compliment_desc` varchar(255) NOT NULL DEFAULT '', >> `status_desc` varchar(255) NOT NULL DEFAULT '', >> `parameter` varchar(255) NOT NULL DEFAULT '', >> `cause` varchar(255) NOT NULL DEFAULT '', >> `disabled` tinyint(1) NOT NULL DEFAULT '0', >> PRIMARY KEY (`id`), >> UNIQUE KEY `index_action_on_cause` (`cause`) >> ) ENGINE=InnoDB AUTO_INCREMENT=56 DEFAULT CHARSET=utf8; >> >> >> >> I see you are running on a 64 bit platform, maybe you can try it also on >>> a 32 bit platform. Maybe >>> you could try accessing the database from windows using the windows >>> my-sql driver. >>> >> >> I reproduced the problem on a 32bit server just right now... >> >> I'll try it on a windows machine asap. >> >> >> 2011/5/3 Hanfei Shen : >> > Hi, >> > >> > Hmmmmmm... The unixODBC is already in my system, but I don't know how >> > to use it... >> > >> > I will setup a vm with fresh system tomorrow to reproduce the problem... >> > >> > PS, could you figure out a name of ANOTHER ODBC-DRIVER which you >> mentioned? >> > >> > 2011/5/3 Hanfei Shen : >> >> Hi, >> >> >> >> I've tried https://github.com/dizzyd/erlang-mysql-driver, it works. >> >> >> >> I'm installing unixodbc... Wait a minute. Thnx... >> >> >> >> >> >> 2011/5/3 Ingela Andin : >> >>> Hi! >> >>> >> >>> Well the best thing would be if you can provide me with a way to >> reproduce it. >> >>> Do you have the possibility to try another odbc-driver with your >> database? >> >>> >> >>> Regards Ingela Erlang/OTP team - Ericsson AB >> >>> >> >>> >> >>> 2011/5/2 Hanfei Shen : >> >>>> Hi, >> >>>> >> >>>> I had changed the type from SQLINTEGER to SQLSMALLINT, but the >> problem >> >>>> is still there... >> >>>> >> >>>> (gdb) i func encode_data_type >> >>>> File odbcserver.c: >> >>>> static void encode_data_type(SQLSMALLINT, SQLINTEGER, SQLSMALLINT, >> db_state *); >> >>>> >> >>>> Breakpoint 1, encode_data_type (sql_type=-9, size=255, >> >>>> decimal_digits=0, state=0x7fffa5380210) at odbcserver.c:1396 >> >>>> 1396 switch(sql_type) { >> >>>> >> >>>> Do you need any details? >> >>>> >> >>>> 2011/5/2 Ingela Anderton Andin : >> >>>>> Hi! >> >>>>> >> >>>>> Hanfei Shen wrote: >> >>>>>> >> >>>>>> Hi Ingela, >> >>>>>> >> >>>>>> Did you mean the value of variable "sql_type"? >> >>>>>> >> >>>>>> >> >>>>> >> >>>>> Yes. >> >>>>> >> >>>>>> I tried to inspect it through gdb, setting a break on func >> >>>>>> encode_data_type. And then I got: >> >>>>>> >> >>>>>> Breakpoint 1, encode_data_type (sql_type=-9, size=255, >> >>>>>> decimal_digits=0, state=0x7fffc657ec40) at odbcserver.c:1396 >> >>>>>> 1396 switch(sql_type) { >> >>>>>> >> >>>>>> >> >>>>> >> >>>>> Well that is defenetly not a good value. Looking at the code just >> now >> >>>>> I noticed that >> >>>>> >> >>>>> encode_data_type defines sql_type as "SQLINTEGER sql_type" and it >> >>>>> ought to be "SQLSMALLINT sql_type". If you change that does it fix >> your >> >>>>> problem? >> >>>>> >> >>>>> Regards Ingela Erlang/OTP team - Ericsson AB >> >>>>> >> >>>>> >> >>>>> >> >>>>>> 2011/5/2 Ingela Andin : >> >>>>>> >> >>>>>>> >> >>>>>>> Hi! >> >>>>>>> >> >>>>>>> The erlang odbc application supports {sql-varchars, N} where N = >> 255 >> >>>>>>> in your case. The return values >> >>>>>>> you get suggest that the odbc-driver you have returns an >> unexpected >> >>>>>>> column type. >> >>>>>>> >> >>>>>>> In the erlang odbc port program there is a switch that handles >> type >> >>>>>>> when describing a coloumn that if we take out >> >>>>>>> the handling code looks like this. >> >>>>>>> >> >>>>>>> switch(sql_type) { >> >>>>>>> case SQL_CHAR: >> >>>>>>> case SQL_VARCHAR: >> >>>>>>> case SQL_WCHAR: >> >>>>>>> case SQL_WVARCHAR: >> >>>>>>> case SQL_NUMERIC: >> >>>>>>> case SQL_DECIMAL: >> >>>>>>> case SQL_INTEGER: >> >>>>>>> case SQL_TINYINT: >> >>>>>>> case SQL_SMALLINT: >> >>>>>>> case SQL_REAL: >> >>>>>>> case SQL_FLOAT: >> >>>>>>> case SQL_DOUBLE: >> >>>>>>> case SQL_BIT: >> >>>>>>> case SQL_TYPE_DATE: >> >>>>>>> case SQL_TYPE_TIME: >> >>>>>>> case SQL_TYPE_TIMESTAMP: >> >>>>>>> case SQL_BIGINT: >> >>>>>>> case SQL_BINARY: >> >>>>>>> case SQL_LONGVARCHAR: >> >>>>>>> case SQL_VARBINARY: >> >>>>>>> case SQL_LONGVARBINARY: >> >>>>>>> case SQL_INTERVAL_MONTH: >> >>>>>>> case SQL_INTERVAL_YEAR: >> >>>>>>> case SQL_INTERVAL_DAY: >> >>>>>>> case SQL_INTERVAL_MINUTE: >> >>>>>>> case SQL_INTERVAL_HOUR_TO_SECOND: >> >>>>>>> case SQL_INTERVAL_MINUTE_TO_SECOND: >> >>>>>>> case SQL_UNKNOWN_TYPE: >> >>>>>>> default: /* Will probably never happen */ >> >>>>>>> ei_x_encode_atom(&dynamic_buffer(state), >> "ODBC_UNSUPPORTED_TYPE"); >> >>>>>>> break; >> >>>>>>> } >> >>>>>>> >> >>>>>>> >> >>>>>>> And you end up in the default clause which is very unexpected and >> the >> >>>>>>> root to your problem. If you can figur out >> >>>>>>> what your driver returns for the ODBC C-API function >> SQLDescribeCol we >> >>>>>>> could know if the driver is at fault or if the odbc-port program >> is. >> >>>>>>> >> >>>>>>> Regards Ingela Erlang/OTP team - Ericsson AB >> >>>>>>> >> >>>>>>> 2011/5/1 Hanfei Shen : >> >>>>>>> >> >>>>>>>> >> >>>>>>>> Dear all, >> >>>>>>>> >> >>>>>>>> I'm a newbie programming in erlang. When I used ODBC to connect >> to a >> >>>>>>>> MySQL database through Connector/ODBC (MyODBC), I got some error >> when >> >>>>>>>> calling odbc:sql_query(Conn, "SELECT * FROM action"): >> >>>>>>>> >> >>>>>>>> {error,"Column type not supported"} >> >>>>>>>> >> >>>>>>>> Then I call odbc:describe_table(Conn, "action"), it returned: >> >>>>>>>> >> >>>>>>>> {ok,[{"id",sql_integer}, >> >>>>>>>> {"code",'ODBC_UNSUPPORTED_TYPE'}, >> >>>>>>>> {"compliment_desc",'ODBC_UNSUPPORTED_TYPE'}, >> >>>>>>>> {"status_desc",'ODBC_UNSUPPORTED_TYPE'}, >> >>>>>>>> {"parameter",'ODBC_UNSUPPORTED_TYPE'}, >> >>>>>>>> {"cause",'ODBC_UNSUPPORTED_TYPE'}, >> >>>>>>>> {"disabled",sql_tinyint}]} >> >>>>>>>> >> >>>>>>>> And desc the table in mysql client: >> >>>>>>>> mysql> desc action; >> >>>>>>>> >> >>>>>>>> >> +-----------------+--------------+------+-----+---------+----------------+ >> >>>>>>>> | Field | Type | Null | Key | Default | Extra >> >>>>>>>> | >> >>>>>>>> >> >>>>>>>> >> +-----------------+--------------+------+-----+---------+----------------+ >> >>>>>>>> | id | int(11) | NO | PRI | NULL | >> auto_increment >> >>>>>>>> | >> >>>>>>>> | code | varchar(255) | NO | | NULL | >> >>>>>>>> | >> >>>>>>>> | compliment_desc | varchar(255) | NO | | | >> >>>>>>>> | >> >>>>>>>> | status_desc | varchar(255) | NO | | | >> >>>>>>>> | >> >>>>>>>> | parameter | varchar(255) | NO | | | >> >>>>>>>> | >> >>>>>>>> | cause | varchar(255) | NO | UNI | | >> >>>>>>>> | >> >>>>>>>> | disabled | tinyint(1) | NO | | 0 | >> >>>>>>>> | >> >>>>>>>> >> >>>>>>>> >> +-----------------+--------------+------+-----+---------+----------------+ >> >>>>>>>> >> >>>>>>>> It seems that Erlang ODBC driver does not support the mysql type >> >>>>>>>> varchar? How can I use the database without touching the db >> schema? >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> Some details about the system env: >> >>>>>>>> >> >>>>>>>> $ uname -a >> >>>>>>>> Linux 2.6.36-gentoo-r8 #4 SMP Thu Apr 7 20:13:18 CST 2011 x86_64 >> >>>>>>>> Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz GenuineIntel GNU/Linux >> >>>>>>>> >> >>>>>>>> $ erl >> >>>>>>>> Erlang R13B04 (erts-5.7.5) [source] [64-bit] [smp:2:2] [rq:2] >> >>>>>>>> [async-threads:0] [kernel-poll:false] >> >>>>>>>> >> >>>>>>>> $ emerge -vp erlang >> >>>>>>>> dev-lang/erlang-13.2.4 USE="doc kpoll odbc smp ssl -emacs -hipe >> -java >> >>>>>>>> -sctp -tk -wxwidgets" >> >>>>>>>> >> >>>>>>>> eshell> code:which(odbc). >> >>>>>>>> "/usr/lib64/erlang/lib/odbc-2.10.7/ebin/odbc.beam" >> >>>>>>>> >> >>>>>>>> $ mysql -V >> >>>>>>>> mysql Ver 14.14 Distrib 5.1.51, for pc-linux-gnu (x86_64) using >> >>>>>>>> readline 5.1 >> >>>>>>>> >> >>>>>>>> Server version: 5.1.51-log Gentoo Linux mysql-5.1.51 >> >>>>>>>> >> >>>>>>>> $ emerge -vp myodbc >> >>>>>>>> dev-db/myodbc-5.1.6 USE="-debug -doc -qt4 -static" >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> Any help will be greatly appreciated. Thanks in advance. >> >>>>>>>> Sorry for my poor English, I'm not a native... >> >>>>>>>> >> >>>>>>>> Best, >> >>>>>>>> >> >>>>>>>> -- >> >>>>>>>> Hanfei >> >>>>>>>> _______________________________________________ >> >>>>>>>> erlang-questions mailing list >> >>>>>>>> erlang-questions@REDACTED >> >>>>>>>> http://erlang.org/mailman/listinfo/erlang-questions >> >>>>>>>> >> >>>>>>>> >> >>>>>> >> >>>>>> >> >>>>> >> >>>>> >> >>>> _______________________________________________ >> >>>> erlang-questions mailing list >> >>>> erlang-questions@REDACTED >> >>>> http://erlang.org/mailman/listinfo/erlang-questions >> >>>> >> >>> >> >> >> > >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fred.hebert@REDACTED Tue May 3 13:26:19 2011 From: fred.hebert@REDACTED (=?iso-8859-1?Q?Fr=E9d=E9ric_Trottier-H=E9bert?=) Date: Tue, 3 May 2011 07:26:19 -0400 Subject: [erlang-questions] Supervisor behaviour In-Reply-To: <7f7a247b-98eb-4cff-9eb2-f7310445d467@z37g2000vbl.googlegroups.com> References: <7f7a247b-98eb-4cff-9eb2-f7310445d467@z37g2000vbl.googlegroups.com> Message-ID: <8796B733-E14B-469C-881C-BEA7A5D156EC@erlang-solutions.com> First point regarding one_for_all restarting all children: you specify you want all children restarted and that's exactly what happens. This is, as far as I know, the normal behaviour. Secondly, the other processes are not restarted when a temporary process crashes because temporary processes are expected to crash -- permanent processes will always trigger a restart, transient processes will trigger a restart if they terminated abnormally and temporary processes will never trigger one. My suggestion if you want to restart your failing temporary process is to make them transient. If, however, you don't want them to be restarted when a permanent process fail, I might suggest you try splitting them into different supervisors with different restart strategies. It's hard to say without knowing what your application is doing, but when you have conflicts in restart strategy, it might mean you are unclear on the responsibilities of each supervisor in terms of isolating processes from each other. -- Fred H?bert http://www.erlang-solutions.com From mrtndimitrov@REDACTED Tue May 3 13:37:50 2011 From: mrtndimitrov@REDACTED (Martin Dimitrov) Date: Tue, 03 May 2011 14:37:50 +0300 Subject: [erlang-questions] Supervisor behaviour In-Reply-To: <8796B733-E14B-469C-881C-BEA7A5D156EC@erlang-solutions.com> References: <7f7a247b-98eb-4cff-9eb2-f7310445d467@z37g2000vbl.googlegroups.com> <8796B733-E14B-469C-881C-BEA7A5D156EC@erlang-solutions.com> Message-ID: <4DBFE90E.3060600@gmail.com> Thanks. I think I got it. one_for_all means *all* child processes will be restarted no matter their type but temporary processes will not trigger a restart. It makes sense now. Thanks for the help. Regards, Martin On 5/3/2011 2:26 PM, Fr?d?ric Trottier-H?bert wrote: > First point regarding one_for_all restarting all children: you specify you want all children restarted and that's exactly what happens. This is, as far as I know, the normal behaviour. > Secondly, the other processes are not restarted when a temporary process crashes because temporary processes are expected to crash -- permanent processes will always trigger a restart, transient processes will trigger a restart if they terminated abnormally and temporary processes will never trigger one. > > My suggestion if you want to restart your failing temporary process is to make them transient. > > If, however, you don't want them to be restarted when a permanent process fail, I might suggest you try splitting them into different supervisors with different restart strategies. It's hard to say without knowing what your application is doing, but when you have conflicts in restart strategy, it might mean you are unclear on the responsibilities of each supervisor in terms of isolating processes from each other. > > -- > Fred H?bert > http://www.erlang-solutions.com From alex.arnon@REDACTED Tue May 3 14:19:33 2011 From: alex.arnon@REDACTED (Alex Arnon) Date: Tue, 3 May 2011 15:19:33 +0300 Subject: [erlang-questions] Looking for RDBMS driver with Transaction Support. In-Reply-To: References: Message-ID: Good - we don't need nested transactions. Thanks! On Tue, May 3, 2011 at 11:11 AM, Robert Raschke wrote: > Just to reiterate Ulf's point, in case you missed it. The standard Erlang > odbc module supports transactions when you odbc:connect/2 using the option > {auto_commit, off}. > > Although, if I remember correctly, nested txns are not supported. > > Robby > > > On Mon, May 2, 2011 at 8:18 PM, Alex Arnon wrote: > >> Thank you all for the solutions, this is very helpful! >> We will evaluate the epgsql and erlang-mysql solutions. >> >> >> >> On Mon, May 2, 2011 at 9:43 PM, Parnell Springmeyer wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> https://github.com/dizzyd/erlang-mysql-driver >>> >>> Look at the tests to see how transactions are used. I use them >>> extensively in my current project. >>> >>> Alex Arnon writes: >>> >>> > Hi All, >>> > >>> > Is there an RDBMS driver in the Erlang universe whose API supports >>> > transactions? >>> > The docs for odbc, epgsql and emysql do not specify any kind of >>> > transaction support. >>> > >>> > Thanks in advance! >>> > >>> > _______________________________________________ >>> > erlang-questions mailing list >>> > erlang-questions@REDACTED >>> > http://erlang.org/mailman/listinfo/erlang-questions >>> >>> - -- >>> Parnell "ixmatus" Springmeyer (http://ixmat.us) >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG/MacGPG2 v2.0.17 (Darwin) >>> Comment: GPGTools - http://gpgtools.org >>> >>> iQEcBAEBAgAGBQJNvvs7AAoJEPvtlbpI1POLvQcH/jyrjTekFE3P0FeF6dn84ROo >>> mAQQWI0cKGM8gLJOJA0kzaf3kEOZ4Ad6qBot2cXU1W5jWBDxRdf0DcvlsGCXx7uN >>> fNOfLCug6/3NNICkCjTUu+mtE1zs3itxj4LU87fbNe9h65MelASwQh7NnXob11A2 >>> 5ylQBXgzEdv6AaPavdO/ej9qRNDA0QieVTFaECW0Pzaly87q9XkBqkgQqoFt34Ta >>> eAbewn90VhuQKB1GZZJDUOH58l57H2RaMKUqSqYMCCmqxwXXAmNUKyNYOsurx7za >>> gCjSEBZ7JvCb+3yyLj6SWlHgTFypYNtZK+861lNLd8i2aKPsOuWHIo/9pkprO94= >>> =PPX8 >>> -----END PGP SIGNATURE----- >>> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas@REDACTED Tue May 3 14:36:11 2011 From: nicolas@REDACTED (Nicolas Niclausse) Date: Tue, 03 May 2011 14:36:11 +0200 Subject: [erlang-questions] GPL3 - EPL compatibility In-Reply-To: References: Message-ID: <4DBFF6BB.7090902@niclux.org> Roberto Majadas Lopez ecrivait le 26/04/2011 20:40: > 2011/4/26 Jesse Gumm > > > You're free to release a program under any license you want. The EPL > pertains to the Erlang language itself, not necessarily to programs > written in Erlang. > > > But if i use erlang crypto server or another one released under EPL . > can this relationship be considered dynamic link ? Hello, http://www.gnu.org/licenses/gpl-faq.html#InterpreterIncompat If i understand well, if you use a library not included in the erlang VM and not compatible with the GPL, it can be a problem. For tsung (GPL also), as suggested in the FAQ, i added an explicit exception giving permission to link with EPL libs, to avoid any license trouble. -- Nicolas From mabrek@REDACTED Tue May 3 14:39:02 2011 From: mabrek@REDACTED (mabrek) Date: Tue, 3 May 2011 16:39:02 +0400 Subject: [erlang-questions] Looking for RDBMS driver with Transaction Support. In-Reply-To: References: Message-ID: On Mon, May 2, 2011 at 10:24 PM, Alex Arnon wrote: > Hi All, > > Is there an RDBMS driver in the Erlang universe whose API supports > transactions? > The docs for odbc, epgsql and emysql do not specify any kind of transaction > support. epgsql does have simple transaction support, take a look at function with_transaction/2 at https://github.com/wg/epgsql/blob/master/src/pgsql.erl Regards, Anton Lebedevich From ingela.andin@REDACTED Tue May 3 14:52:49 2011 From: ingela.andin@REDACTED (Ingela Andin) Date: Tue, 3 May 2011 14:52:49 +0200 Subject: [erlang-questions] Erlang and MySQL: ODBC, Column type not supported In-Reply-To: References: <4DBE7B49.1080505@erix.ericsson.se> Message-ID: Hi! Interesting what does odbc:describe_table/2 return on R14B02 ? Regards Ingela Erlang/OTP team - Ericsson AB 2011/5/3 Hanfei Shen : > Hi, > > Well it works on R14B02... > > 2011/5/3 Hanfei Shen >> >> Hi, >> >> The same on my windows 7 32 bit workstation. >> >> Erlang R13B02 (erts-5.7.3) >> >> 4> code:which(odbc). >> "d:/PROGRA~1/ERL57~1.3/lib/odbc-2.10.5/ebin/odbc.beam" >> >> mysql odbc 5.1.8 >> >> >> >> I'm downloading the latest version of erlang (R14B02)... >> >> >> 2011/5/3 Hanfei Shen >>> >>> Hi, >>> >>> I had set up a fresh system and reproduce this problem successfully. >>> Here is something about my installations: >>> >>> vm: >>> VirtualBox 4.0.6 r71416 >>> >>> gentoo: >>> livecd: install-amd64-minimal-20110317.iso >>> stage: stage3-amd64-20110428.tar.bz2 >>> portage: portage-20110424.tar.bz2 >>> >>> I only installed: >>> >>> dev-db/mysql-5.1.51 >>> dev-db/myodbc-5.1.6 >>> dev-lang/erlang-13.2.4 USE="kpoll odbc smp" >>> >>> table schema: >>> >>> CREATE TABLE `action` ( >>> ? `id` int(11) NOT NULL AUTO_INCREMENT, >>> ? `code` varchar(255) NOT NULL, >>> ? `compliment_desc` varchar(255) NOT NULL DEFAULT '', >>> ? `status_desc` varchar(255) NOT NULL DEFAULT '', >>> ? `parameter` varchar(255) NOT NULL DEFAULT '', >>> ? `cause` varchar(255) NOT NULL DEFAULT '', >>> ? `disabled` tinyint(1) NOT NULL DEFAULT '0', >>> ? PRIMARY KEY (`id`), >>> ? UNIQUE KEY `index_action_on_cause` (`cause`) >>> ) ENGINE=InnoDB AUTO_INCREMENT=56 DEFAULT CHARSET=utf8; >>> >>> >>>> I see you are running on a 64 bit ?platform, maybe you can try ?it also >>>> on a 32 bit platform. ?Maybe >>>> you could try accessing the database from windows using the windows >>>> my-sql driver. >>> >>> I reproduced the problem on a 32bit server just right now... >>> >>> I'll try it on a windows machine asap. >>> >>> 2011/5/3 Hanfei Shen : >>> > Hi, >>> > >>> > Hmmmmmm... The unixODBC is already in my system, but I don't know how >>> > to use it... >>> > >>> > I will setup a vm with fresh system tomorrow to reproduce the >>> > problem... >>> > >>> > PS, could you figure out a name of ANOTHER ODBC-DRIVER which you >>> > mentioned? >>> > >>> > 2011/5/3 Hanfei Shen : >>> >> Hi, >>> >> >>> >> I've tried https://github.com/dizzyd/erlang-mysql-driver, it works. >>> >> >>> >> I'm installing unixodbc... Wait a minute. Thnx... >>> >> >>> >> >>> >> 2011/5/3 Ingela Andin : >>> >>> Hi! >>> >>> >>> >>> Well the best thing would be if you can provide me with a way to >>> >>> reproduce it. >>> >>> Do you have the possibility to try another odbc-driver with your >>> >>> database? >>> >>> >>> >>> Regards Ingela Erlang/OTP team - Ericsson AB >>> >>> >>> >>> >>> >>> 2011/5/2 Hanfei Shen : >>> >>>> Hi, >>> >>>> >>> >>>> I had changed the type from SQLINTEGER to SQLSMALLINT, but the >>> >>>> problem >>> >>>> is still there... >>> >>>> >>> >>>> (gdb) i func encode_data_type >>> >>>> File odbcserver.c: >>> >>>> static void encode_data_type(SQLSMALLINT, SQLINTEGER, SQLSMALLINT, >>> >>>> db_state *); >>> >>>> >>> >>>> Breakpoint 1, encode_data_type (sql_type=-9, size=255, >>> >>>> decimal_digits=0, state=0x7fffa5380210) at odbcserver.c:1396 >>> >>>> 1396 ? ? ? ?switch(sql_type) { >>> >>>> >>> >>>> Do you need any details? >>> >>>> >>> >>>> 2011/5/2 Ingela Anderton Andin : >>> >>>>> Hi! >>> >>>>> >>> >>>>> Hanfei Shen wrote: >>> >>>>>> >>> >>>>>> Hi Ingela, >>> >>>>>> >>> >>>>>> Did you mean the value of variable "sql_type"? >>> >>>>>> >>> >>>>>> >>> >>>>> >>> >>>>> Yes. >>> >>>>> >>> >>>>>> I tried to inspect it through gdb, setting a break on func >>> >>>>>> encode_data_type. And then I got: >>> >>>>>> >>> >>>>>> Breakpoint 1, encode_data_type (sql_type=-9, size=255, >>> >>>>>> decimal_digits=0, state=0x7fffc657ec40) at odbcserver.c:1396 >>> >>>>>> 1396 ? ? ? ?switch(sql_type) { >>> >>>>>> >>> >>>>>> >>> >>>>> >>> >>>>> Well that is defenetly not a good value. Looking at the code just >>> >>>>> now >>> >>>>> I noticed that >>> >>>>> >>> >>>>> encode_data_type defines sql_type as "SQLINTEGER sql_type" and it >>> >>>>> ought to be "SQLSMALLINT sql_type". If you change that does it fix >>> >>>>> your >>> >>>>> problem? >>> >>>>> >>> >>>>> Regards Ingela Erlang/OTP team - Ericsson AB >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>>> 2011/5/2 Ingela Andin : >>> >>>>>> >>> >>>>>>> >>> >>>>>>> Hi! >>> >>>>>>> >>> >>>>>>> The erlang odbc application supports {sql-varchars, ?N} where N = >>> >>>>>>> 255 >>> >>>>>>> in your case. The return values >>> >>>>>>> you get suggest that the odbc-driver you have returns an >>> >>>>>>> unexpected >>> >>>>>>> column type. >>> >>>>>>> >>> >>>>>>> In the erlang odbc port program there is a switch that handles >>> >>>>>>> type >>> >>>>>>> when describing a coloumn that if we take out >>> >>>>>>> the handling code looks like this. >>> >>>>>>> >>> >>>>>>> switch(sql_type) { >>> >>>>>>> ? case SQL_CHAR: >>> >>>>>>> ? case SQL_VARCHAR: >>> >>>>>>> ? case SQL_WCHAR: >>> >>>>>>> ? case SQL_WVARCHAR: >>> >>>>>>> ? case SQL_NUMERIC: >>> >>>>>>> ? case SQL_DECIMAL: >>> >>>>>>> ? case SQL_INTEGER: >>> >>>>>>> ? case SQL_TINYINT: >>> >>>>>>> ? case SQL_SMALLINT: >>> >>>>>>> ? case SQL_REAL: >>> >>>>>>> ? case SQL_FLOAT: >>> >>>>>>> ? case SQL_DOUBLE: >>> >>>>>>> ? case SQL_BIT: >>> >>>>>>> ? case SQL_TYPE_DATE: >>> >>>>>>> ? case SQL_TYPE_TIME: >>> >>>>>>> ? case SQL_TYPE_TIMESTAMP: >>> >>>>>>> ? case SQL_BIGINT: >>> >>>>>>> ? case SQL_BINARY: >>> >>>>>>> ? case SQL_LONGVARCHAR: >>> >>>>>>> ? case SQL_VARBINARY: >>> >>>>>>> ? case SQL_LONGVARBINARY: >>> >>>>>>> ? case SQL_INTERVAL_MONTH: >>> >>>>>>> ? case SQL_INTERVAL_YEAR: >>> >>>>>>> ? case SQL_INTERVAL_DAY: >>> >>>>>>> ? case SQL_INTERVAL_MINUTE: >>> >>>>>>> ? case SQL_INTERVAL_HOUR_TO_SECOND: >>> >>>>>>> ? case SQL_INTERVAL_MINUTE_TO_SECOND: >>> >>>>>>> ? case SQL_UNKNOWN_TYPE: >>> >>>>>>> ? default: /* Will probably never happen */ >>> >>>>>>> ? ? ? ei_x_encode_atom(&dynamic_buffer(state), >>> >>>>>>> "ODBC_UNSUPPORTED_TYPE"); >>> >>>>>>> ? ? ? break; >>> >>>>>>> ? } >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> And you end up in the default clause which is very unexpected and >>> >>>>>>> the >>> >>>>>>> root to your problem. ?If ?you can figur out >>> >>>>>>> what your driver returns for the ODBC C-API function >>> >>>>>>> SQLDescribeCol we >>> >>>>>>> could know if the driver is at fault or if the odbc-port program >>> >>>>>>> is. >>> >>>>>>> >>> >>>>>>> Regards ?Ingela Erlang/OTP team - Ericsson AB >>> >>>>>>> >>> >>>>>>> 2011/5/1 Hanfei Shen : >>> >>>>>>> >>> >>>>>>>> >>> >>>>>>>> Dear all, >>> >>>>>>>> >>> >>>>>>>> I'm a newbie programming in erlang. When I used ODBC to connect >>> >>>>>>>> to a >>> >>>>>>>> MySQL database through Connector/ODBC (MyODBC), I got some error >>> >>>>>>>> when >>> >>>>>>>> calling odbc:sql_query(Conn, "SELECT * FROM action"): >>> >>>>>>>> >>> >>>>>>>> {error,"Column type not supported"} >>> >>>>>>>> >>> >>>>>>>> Then I call odbc:describe_table(Conn, "action"), it returned: >>> >>>>>>>> >>> >>>>>>>> {ok,[{"id",sql_integer}, >>> >>>>>>>> ? ? {"code",'ODBC_UNSUPPORTED_TYPE'}, >>> >>>>>>>> ? ? {"compliment_desc",'ODBC_UNSUPPORTED_TYPE'}, >>> >>>>>>>> ? ? {"status_desc",'ODBC_UNSUPPORTED_TYPE'}, >>> >>>>>>>> ? ? {"parameter",'ODBC_UNSUPPORTED_TYPE'}, >>> >>>>>>>> ? ? {"cause",'ODBC_UNSUPPORTED_TYPE'}, >>> >>>>>>>> ? ? {"disabled",sql_tinyint}]} >>> >>>>>>>> >>> >>>>>>>> And desc the table in mysql client: >>> >>>>>>>> mysql> desc action; >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> +-----------------+--------------+------+-----+---------+----------------+ >>> >>>>>>>> | Field ? ? ? ? ? | Type ? ? ? ? | Null | Key | Default | Extra >>> >>>>>>>> ?| >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> +-----------------+--------------+------+-----+---------+----------------+ >>> >>>>>>>> | id ? ? ? ? ? ? ?| int(11) ? ? ?| NO ? | PRI | NULL ? ?| >>> >>>>>>>> auto_increment >>> >>>>>>>> | >>> >>>>>>>> | code ? ? ? ? ? ?| varchar(255) | NO ? | ? ? | NULL ? ?| >>> >>>>>>>> ?| >>> >>>>>>>> | compliment_desc | varchar(255) | NO ? | ? ? | ? ? ? ? | >>> >>>>>>>> ?| >>> >>>>>>>> | status_desc ? ? | varchar(255) | NO ? | ? ? | ? ? ? ? | >>> >>>>>>>> ?| >>> >>>>>>>> | parameter ? ? ? | varchar(255) | NO ? | ? ? | ? ? ? ? | >>> >>>>>>>> ?| >>> >>>>>>>> | cause ? ? ? ? ? | varchar(255) | NO ? | UNI | ? ? ? ? | >>> >>>>>>>> ?| >>> >>>>>>>> | disabled ? ? ? ?| tinyint(1) ? | NO ? | ? ? | 0 ? ? ? | >>> >>>>>>>> ?| >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> +-----------------+--------------+------+-----+---------+----------------+ >>> >>>>>>>> >>> >>>>>>>> It seems that Erlang ODBC driver does not support the mysql type >>> >>>>>>>> varchar? How can I use the database without touching the db >>> >>>>>>>> schema? >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> Some details about the system env: >>> >>>>>>>> >>> >>>>>>>> $ uname -a >>> >>>>>>>> Linux 2.6.36-gentoo-r8 #4 SMP Thu Apr 7 20:13:18 CST 2011 x86_64 >>> >>>>>>>> Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz GenuineIntel >>> >>>>>>>> GNU/Linux >>> >>>>>>>> >>> >>>>>>>> $ erl >>> >>>>>>>> Erlang R13B04 (erts-5.7.5) [source] [64-bit] [smp:2:2] [rq:2] >>> >>>>>>>> [async-threads:0] [kernel-poll:false] >>> >>>>>>>> >>> >>>>>>>> $ emerge -vp erlang >>> >>>>>>>> dev-lang/erlang-13.2.4 ?USE="doc kpoll odbc smp ssl -emacs -hipe >>> >>>>>>>> -java >>> >>>>>>>> -sctp -tk -wxwidgets" >>> >>>>>>>> >>> >>>>>>>> eshell> code:which(odbc). >>> >>>>>>>> "/usr/lib64/erlang/lib/odbc-2.10.7/ebin/odbc.beam" >>> >>>>>>>> >>> >>>>>>>> $ mysql -V >>> >>>>>>>> mysql ?Ver 14.14 Distrib 5.1.51, for pc-linux-gnu (x86_64) using >>> >>>>>>>> readline 5.1 >>> >>>>>>>> >>> >>>>>>>> Server version: 5.1.51-log Gentoo Linux mysql-5.1.51 >>> >>>>>>>> >>> >>>>>>>> $ emerge -vp myodbc >>> >>>>>>>> dev-db/myodbc-5.1.6 ?USE="-debug -doc -qt4 -static" >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> Any help will be greatly appreciated. ?Thanks in advance. >>> >>>>>>>> Sorry for my poor English, I'm not a native... >>> >>>>>>>> >>> >>>>>>>> Best, >>> >>>>>>>> >>> >>>>>>>> -- >>> >>>>>>>> Hanfei >>> >>>>>>>> _______________________________________________ >>> >>>>>>>> erlang-questions mailing list >>> >>>>>>>> erlang-questions@REDACTED >>> >>>>>>>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>> >>> >>>>> >>> >>>> _______________________________________________ >>> >>>> erlang-questions mailing list >>> >>>> erlang-questions@REDACTED >>> >>>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>>> >>> >>> >>> >> >>> > >>> >> > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > From nick@REDACTED Tue May 3 15:35:47 2011 From: nick@REDACTED (Niclas Eklund) Date: Tue, 3 May 2011 15:35:47 +0200 Subject: [erlang-questions] Errors when generating tests for CosNotifications on windows. In-Reply-To: References: Message-ID: Hello! As you've probably guessed we don't encounter this problem. ;-) But then the test suites are only built once (not a Windows machine) and then re-used by different plattforms. Speed things up. Since there is a 256 chars limit (Windows paths and command line), this might be it. I suppose that a faulty setting of one of the Erlang related environment variables (e.g. ERL_TOP) could cause problems as well. Perhaps you can e-mail them to me? Due to the fact that CosNotification depends on several other Cos-services, more IDL files needs to be included compared with, for example, CosTime. Best Regards, Niclas @ Erlang/OTP On Thu, 21 Apr 2011, Fredrik Andersson wrote: > On Thu, Apr 21, 2011 at 11:04 AM, Alexander Krasnukhin < > the.malkolm@REDACTED> wrote: > >> Hi, >> >> It is just a guess and probably sounds stupid but could you try to compile >> within the folder with smaller path length? >> > > I tried moving the otp folder to / and it had no difference, I can make them > all compile if I cp the idl files to the test folder of cosNotification but > that seems to be a suboptimal way of doing things. > > >> >> On Thu, Apr 21, 2011 at 10:57 AM, Fredrik Andersson wrote: >> >>> Hi all >>> >>> I want to run the test suites on my windows build but I am running into >>> trouble when generating the tests for CosNotification. I can reproduce the >>> error by building the tests inside of otp/lib/CosNotification/test using >>> make tests. >>> >>> Can anyone help? >>> >>> The following is the error I get. I have verified that the idl files are >>> present in the src directory. >>> >>> erlc +debug_info -pa >>> /home/ESLbingen/bingen/tmp/otp/lib/cosNotification/ebin -pa >>> /home/ESLbingen/bingen/tmp/otp/lib/cosNotification/src -pa >>> /home/ESLbingen/bingen/tmp/otp/lib/cosTime/ebin -pa >>> /home/ESLbingen/bingen/tmp/otp/lib/cosTime/include -pa >>> /home/ESLbingen/bingen/tmp/otp/lib/orber/ebin -pa >>> /home/ESLbingen/bingen/tmp/otp/lib/ic/ebin -pa >>> /home/ESLbingen/bingen/tmp/otp/lib/cosNotification/include >>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosEvent/src >>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosNotification/include -pa >>> /home/ESLbingen/bingen/tmp/otp/lib/orber/include -pa >>> /home/ESLbingen/bingen/tmp/otp/internal_tools/test_server/ebin -pa >>> /home/ESLbingen/bingen/tmp/otp/lib/cosNotification/ebin -pa >>> /home/ESLbingen/bingen/tmp/otp/lib/cosNotification/test/idl_output -pa >>> /home/ESLbingen/bingen/tmp/otp/lib/cosTime/ebin -pa >>> /home/ESLbingen/bingen/tmp/otp/lib/cosTime/include -pa >>> /home/ESLbingen/bingen/tmp/otp/lib/cosNotification/include -pa >>> /home/ESLbingen/bingen/tmp/otp/lib/ic/ebin >>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosTime/ebin >>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosTime/include >>> -I/home/ESLbingen/bingen/tmp/otp/lib/orber/include >>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosNotification/src >>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosNotification/include >>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosNotification >>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosNotification/test/idl_output >>> -I/home/ESLbingen/bingen/tmp/otp/lib/test_server/include -oidl_output \ >>> +'{cfgfile,"notify_test_server.cfg"}' >>> notify_test_server.idl >>> []: warning: unrecognised option: debug_info >>> Erlang IDL compiler version 4.2.26 >>> "c:/cygwin/home/ESLBIN~1/bingen/tmp/otp/lib/COSNOT~1/test/notify_test_server.idl": >>> preprocessor error: >>> c:/cygwin/home/ESLBIN~1/bingen/tmp/otp/lib/COSNOT~1/test/notify_test_server.idl:23: >>> CosNotification.idl: No such file or directory >>> "c:/cygwin/home/ESLBIN~1/bingen/tmp/otp/lib/COSNOT~1/test/notify_test_server.idl": >>> preprocessor error: >>> c:/cygwin/home/ESLBIN~1/bingen/tmp/otp/lib/COSNOT~1/test/notify_test_server.idl:24: >>> CosNotifyComm.idl: No such file or directory >>> "c:/cygwin/home/ESLBIN~1/bingen/tmp/otp/lib/COSNOT~1/test/notify_test_server.idl": >>> 2 errors found >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >> >> >> -- >> Regards, >> Alexander >> >> > From qqshfox@REDACTED Tue May 3 16:10:37 2011 From: qqshfox@REDACTED (Hanfei Shen) Date: Tue, 3 May 2011 22:10:37 +0800 Subject: [erlang-questions] Erlang and MySQL: ODBC, Column type not supported In-Reply-To: References: <4DBE7B49.1080505@erix.ericsson.se> Message-ID: Hi, It returns: {ok,[{"id",sql_integer}, {"code",{sql_wvarchar,255}}, {"compliment_desc",{sql_wvarchar,255}}, {"status_desc",{sql_wvarchar,255}}, {"parameter",{sql_wvarchar,255}}, {"cause",{sql_wvarchar,255}}, {"disabled",sql_tinyint}]} I found that the macro SQL_WVARCHAR is defined in sqlucode.h. 2011/5/3 Ingela Andin > Hi! > > Interesting what does odbc:describe_table/2 return on > R14B02 ? > > Regards Ingela Erlang/OTP team - Ericsson AB > > > 2011/5/3 Hanfei Shen : > > Hi, > > > > Well it works on R14B02... > > > > 2011/5/3 Hanfei Shen > >> > >> Hi, > >> > >> The same on my windows 7 32 bit workstation. > >> > >> Erlang R13B02 (erts-5.7.3) > >> > >> 4> code:which(odbc). > >> "d:/PROGRA~1/ERL57~1.3/lib/odbc-2.10.5/ebin/odbc.beam" > >> > >> mysql odbc 5.1.8 > >> > >> > >> > >> I'm downloading the latest version of erlang (R14B02)... > >> > >> > >> 2011/5/3 Hanfei Shen > >>> > >>> Hi, > >>> > >>> I had set up a fresh system and reproduce this problem successfully. > >>> Here is something about my installations: > >>> > >>> vm: > >>> VirtualBox 4.0.6 r71416 > >>> > >>> gentoo: > >>> livecd: install-amd64-minimal-20110317.iso > >>> stage: stage3-amd64-20110428.tar.bz2 > >>> portage: portage-20110424.tar.bz2 > >>> > >>> I only installed: > >>> > >>> dev-db/mysql-5.1.51 > >>> dev-db/myodbc-5.1.6 > >>> dev-lang/erlang-13.2.4 USE="kpoll odbc smp" > >>> > >>> table schema: > >>> > >>> CREATE TABLE `action` ( > >>> `id` int(11) NOT NULL AUTO_INCREMENT, > >>> `code` varchar(255) NOT NULL, > >>> `compliment_desc` varchar(255) NOT NULL DEFAULT '', > >>> `status_desc` varchar(255) NOT NULL DEFAULT '', > >>> `parameter` varchar(255) NOT NULL DEFAULT '', > >>> `cause` varchar(255) NOT NULL DEFAULT '', > >>> `disabled` tinyint(1) NOT NULL DEFAULT '0', > >>> PRIMARY KEY (`id`), > >>> UNIQUE KEY `index_action_on_cause` (`cause`) > >>> ) ENGINE=InnoDB AUTO_INCREMENT=56 DEFAULT CHARSET=utf8; > >>> > >>> > >>>> I see you are running on a 64 bit platform, maybe you can try it > also > >>>> on a 32 bit platform. Maybe > >>>> you could try accessing the database from windows using the windows > >>>> my-sql driver. > >>> > >>> I reproduced the problem on a 32bit server just right now... > >>> > >>> I'll try it on a windows machine asap. > >>> > >>> 2011/5/3 Hanfei Shen : > >>> > Hi, > >>> > > >>> > Hmmmmmm... The unixODBC is already in my system, but I don't know how > >>> > to use it... > >>> > > >>> > I will setup a vm with fresh system tomorrow to reproduce the > >>> > problem... > >>> > > >>> > PS, could you figure out a name of ANOTHER ODBC-DRIVER which you > >>> > mentioned? > >>> > > >>> > 2011/5/3 Hanfei Shen : > >>> >> Hi, > >>> >> > >>> >> I've tried https://github.com/dizzyd/erlang-mysql-driver, it works. > >>> >> > >>> >> I'm installing unixodbc... Wait a minute. Thnx... > >>> >> > >>> >> > >>> >> 2011/5/3 Ingela Andin : > >>> >>> Hi! > >>> >>> > >>> >>> Well the best thing would be if you can provide me with a way to > >>> >>> reproduce it. > >>> >>> Do you have the possibility to try another odbc-driver with your > >>> >>> database? > >>> >>> > >>> >>> Regards Ingela Erlang/OTP team - Ericsson AB > >>> >>> > >>> >>> > >>> >>> 2011/5/2 Hanfei Shen : > >>> >>>> Hi, > >>> >>>> > >>> >>>> I had changed the type from SQLINTEGER to SQLSMALLINT, but the > >>> >>>> problem > >>> >>>> is still there... > >>> >>>> > >>> >>>> (gdb) i func encode_data_type > >>> >>>> File odbcserver.c: > >>> >>>> static void encode_data_type(SQLSMALLINT, SQLINTEGER, SQLSMALLINT, > >>> >>>> db_state *); > >>> >>>> > >>> >>>> Breakpoint 1, encode_data_type (sql_type=-9, size=255, > >>> >>>> decimal_digits=0, state=0x7fffa5380210) at odbcserver.c:1396 > >>> >>>> 1396 switch(sql_type) { > >>> >>>> > >>> >>>> Do you need any details? > >>> >>>> > >>> >>>> 2011/5/2 Ingela Anderton Andin : > >>> >>>>> Hi! > >>> >>>>> > >>> >>>>> Hanfei Shen wrote: > >>> >>>>>> > >>> >>>>>> Hi Ingela, > >>> >>>>>> > >>> >>>>>> Did you mean the value of variable "sql_type"? > >>> >>>>>> > >>> >>>>>> > >>> >>>>> > >>> >>>>> Yes. > >>> >>>>> > >>> >>>>>> I tried to inspect it through gdb, setting a break on func > >>> >>>>>> encode_data_type. And then I got: > >>> >>>>>> > >>> >>>>>> Breakpoint 1, encode_data_type (sql_type=-9, size=255, > >>> >>>>>> decimal_digits=0, state=0x7fffc657ec40) at odbcserver.c:1396 > >>> >>>>>> 1396 switch(sql_type) { > >>> >>>>>> > >>> >>>>>> > >>> >>>>> > >>> >>>>> Well that is defenetly not a good value. Looking at the code just > >>> >>>>> now > >>> >>>>> I noticed that > >>> >>>>> > >>> >>>>> encode_data_type defines sql_type as "SQLINTEGER sql_type" and it > >>> >>>>> ought to be "SQLSMALLINT sql_type". If you change that does it > fix > >>> >>>>> your > >>> >>>>> problem? > >>> >>>>> > >>> >>>>> Regards Ingela Erlang/OTP team - Ericsson AB > >>> >>>>> > >>> >>>>> > >>> >>>>> > >>> >>>>>> 2011/5/2 Ingela Andin : > >>> >>>>>> > >>> >>>>>>> > >>> >>>>>>> Hi! > >>> >>>>>>> > >>> >>>>>>> The erlang odbc application supports {sql-varchars, N} where N > = > >>> >>>>>>> 255 > >>> >>>>>>> in your case. The return values > >>> >>>>>>> you get suggest that the odbc-driver you have returns an > >>> >>>>>>> unexpected > >>> >>>>>>> column type. > >>> >>>>>>> > >>> >>>>>>> In the erlang odbc port program there is a switch that handles > >>> >>>>>>> type > >>> >>>>>>> when describing a coloumn that if we take out > >>> >>>>>>> the handling code looks like this. > >>> >>>>>>> > >>> >>>>>>> switch(sql_type) { > >>> >>>>>>> case SQL_CHAR: > >>> >>>>>>> case SQL_VARCHAR: > >>> >>>>>>> case SQL_WCHAR: > >>> >>>>>>> case SQL_WVARCHAR: > >>> >>>>>>> case SQL_NUMERIC: > >>> >>>>>>> case SQL_DECIMAL: > >>> >>>>>>> case SQL_INTEGER: > >>> >>>>>>> case SQL_TINYINT: > >>> >>>>>>> case SQL_SMALLINT: > >>> >>>>>>> case SQL_REAL: > >>> >>>>>>> case SQL_FLOAT: > >>> >>>>>>> case SQL_DOUBLE: > >>> >>>>>>> case SQL_BIT: > >>> >>>>>>> case SQL_TYPE_DATE: > >>> >>>>>>> case SQL_TYPE_TIME: > >>> >>>>>>> case SQL_TYPE_TIMESTAMP: > >>> >>>>>>> case SQL_BIGINT: > >>> >>>>>>> case SQL_BINARY: > >>> >>>>>>> case SQL_LONGVARCHAR: > >>> >>>>>>> case SQL_VARBINARY: > >>> >>>>>>> case SQL_LONGVARBINARY: > >>> >>>>>>> case SQL_INTERVAL_MONTH: > >>> >>>>>>> case SQL_INTERVAL_YEAR: > >>> >>>>>>> case SQL_INTERVAL_DAY: > >>> >>>>>>> case SQL_INTERVAL_MINUTE: > >>> >>>>>>> case SQL_INTERVAL_HOUR_TO_SECOND: > >>> >>>>>>> case SQL_INTERVAL_MINUTE_TO_SECOND: > >>> >>>>>>> case SQL_UNKNOWN_TYPE: > >>> >>>>>>> default: /* Will probably never happen */ > >>> >>>>>>> ei_x_encode_atom(&dynamic_buffer(state), > >>> >>>>>>> "ODBC_UNSUPPORTED_TYPE"); > >>> >>>>>>> break; > >>> >>>>>>> } > >>> >>>>>>> > >>> >>>>>>> > >>> >>>>>>> And you end up in the default clause which is very unexpected > and > >>> >>>>>>> the > >>> >>>>>>> root to your problem. If you can figur out > >>> >>>>>>> what your driver returns for the ODBC C-API function > >>> >>>>>>> SQLDescribeCol we > >>> >>>>>>> could know if the driver is at fault or if the odbc-port > program > >>> >>>>>>> is. > >>> >>>>>>> > >>> >>>>>>> Regards Ingela Erlang/OTP team - Ericsson AB > >>> >>>>>>> > >>> >>>>>>> 2011/5/1 Hanfei Shen : > >>> >>>>>>> > >>> >>>>>>>> > >>> >>>>>>>> Dear all, > >>> >>>>>>>> > >>> >>>>>>>> I'm a newbie programming in erlang. When I used ODBC to > connect > >>> >>>>>>>> to a > >>> >>>>>>>> MySQL database through Connector/ODBC (MyODBC), I got some > error > >>> >>>>>>>> when > >>> >>>>>>>> calling odbc:sql_query(Conn, "SELECT * FROM action"): > >>> >>>>>>>> > >>> >>>>>>>> {error,"Column type not supported"} > >>> >>>>>>>> > >>> >>>>>>>> Then I call odbc:describe_table(Conn, "action"), it returned: > >>> >>>>>>>> > >>> >>>>>>>> {ok,[{"id",sql_integer}, > >>> >>>>>>>> {"code",'ODBC_UNSUPPORTED_TYPE'}, > >>> >>>>>>>> {"compliment_desc",'ODBC_UNSUPPORTED_TYPE'}, > >>> >>>>>>>> {"status_desc",'ODBC_UNSUPPORTED_TYPE'}, > >>> >>>>>>>> {"parameter",'ODBC_UNSUPPORTED_TYPE'}, > >>> >>>>>>>> {"cause",'ODBC_UNSUPPORTED_TYPE'}, > >>> >>>>>>>> {"disabled",sql_tinyint}]} > >>> >>>>>>>> > >>> >>>>>>>> And desc the table in mysql client: > >>> >>>>>>>> mysql> desc action; > >>> >>>>>>>> > >>> >>>>>>>> > >>> >>>>>>>> > +-----------------+--------------+------+-----+---------+----------------+ > >>> >>>>>>>> | Field | Type | Null | Key | Default | > Extra > >>> >>>>>>>> | > >>> >>>>>>>> > >>> >>>>>>>> > >>> >>>>>>>> > +-----------------+--------------+------+-----+---------+----------------+ > >>> >>>>>>>> | id | int(11) | NO | PRI | NULL | > >>> >>>>>>>> auto_increment > >>> >>>>>>>> | > >>> >>>>>>>> | code | varchar(255) | NO | | NULL | > >>> >>>>>>>> | > >>> >>>>>>>> | compliment_desc | varchar(255) | NO | | | > >>> >>>>>>>> | > >>> >>>>>>>> | status_desc | varchar(255) | NO | | | > >>> >>>>>>>> | > >>> >>>>>>>> | parameter | varchar(255) | NO | | | > >>> >>>>>>>> | > >>> >>>>>>>> | cause | varchar(255) | NO | UNI | | > >>> >>>>>>>> | > >>> >>>>>>>> | disabled | tinyint(1) | NO | | 0 | > >>> >>>>>>>> | > >>> >>>>>>>> > >>> >>>>>>>> > >>> >>>>>>>> > +-----------------+--------------+------+-----+---------+----------------+ > >>> >>>>>>>> > >>> >>>>>>>> It seems that Erlang ODBC driver does not support the mysql > type > >>> >>>>>>>> varchar? How can I use the database without touching the db > >>> >>>>>>>> schema? > >>> >>>>>>>> > >>> >>>>>>>> > >>> >>>>>>>> Some details about the system env: > >>> >>>>>>>> > >>> >>>>>>>> $ uname -a > >>> >>>>>>>> Linux 2.6.36-gentoo-r8 #4 SMP Thu Apr 7 20:13:18 CST 2011 > x86_64 > >>> >>>>>>>> Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz GenuineIntel > >>> >>>>>>>> GNU/Linux > >>> >>>>>>>> > >>> >>>>>>>> $ erl > >>> >>>>>>>> Erlang R13B04 (erts-5.7.5) [source] [64-bit] [smp:2:2] [rq:2] > >>> >>>>>>>> [async-threads:0] [kernel-poll:false] > >>> >>>>>>>> > >>> >>>>>>>> $ emerge -vp erlang > >>> >>>>>>>> dev-lang/erlang-13.2.4 USE="doc kpoll odbc smp ssl -emacs > -hipe > >>> >>>>>>>> -java > >>> >>>>>>>> -sctp -tk -wxwidgets" > >>> >>>>>>>> > >>> >>>>>>>> eshell> code:which(odbc). > >>> >>>>>>>> "/usr/lib64/erlang/lib/odbc-2.10.7/ebin/odbc.beam" > >>> >>>>>>>> > >>> >>>>>>>> $ mysql -V > >>> >>>>>>>> mysql Ver 14.14 Distrib 5.1.51, for pc-linux-gnu (x86_64) > using > >>> >>>>>>>> readline 5.1 > >>> >>>>>>>> > >>> >>>>>>>> Server version: 5.1.51-log Gentoo Linux mysql-5.1.51 > >>> >>>>>>>> > >>> >>>>>>>> $ emerge -vp myodbc > >>> >>>>>>>> dev-db/myodbc-5.1.6 USE="-debug -doc -qt4 -static" > >>> >>>>>>>> > >>> >>>>>>>> > >>> >>>>>>>> Any help will be greatly appreciated. Thanks in advance. > >>> >>>>>>>> Sorry for my poor English, I'm not a native... > >>> >>>>>>>> > >>> >>>>>>>> Best, > >>> >>>>>>>> > >>> >>>>>>>> -- > >>> >>>>>>>> Hanfei > >>> >>>>>>>> _______________________________________________ > >>> >>>>>>>> erlang-questions mailing list > >>> >>>>>>>> erlang-questions@REDACTED > >>> >>>>>>>> http://erlang.org/mailman/listinfo/erlang-questions > >>> >>>>>>>> > >>> >>>>>>>> > >>> >>>>>> > >>> >>>>>> > >>> >>>>> > >>> >>>>> > >>> >>>> _______________________________________________ > >>> >>>> erlang-questions mailing list > >>> >>>> erlang-questions@REDACTED > >>> >>>> http://erlang.org/mailman/listinfo/erlang-questions > >>> >>>> > >>> >>> > >>> >> > >>> > > >>> > >> > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ingela.andin@REDACTED Tue May 3 16:29:25 2011 From: ingela.andin@REDACTED (Ingela Andin) Date: Tue, 3 May 2011 16:29:25 +0200 Subject: [erlang-questions] Erlang and MySQL: ODBC, Column type not supported In-Reply-To: References: <4DBE7B49.1080505@erix.ericsson.se> Message-ID: Hi! Ok problem solved then, from the releasenotes of odbc version 2.10.8: "1.3 ODBC 2.10.8 Improvements and New Features * ODBC now handles the types SQL_WCHAR and SQL_WVARCHAR. Thanks to Juhani R?nkimies. ODBC also has a new connection option to return all strings as binaries and also expect strings to be binaries in the param_query function. These changes provides some unicode support. Own Id: OTP-7452" You had version 2.10.7 and latest version (in R14B02) is 2.10.10. Regards Ingela Erlang/OTP team - Ericsson AB 2011/5/3 Hanfei Shen : > Hi, > > It returns: > > {ok,[{"id",sql_integer}, > ???? {"code",{sql_wvarchar,255}}, > ???? {"compliment_desc",{sql_wvarchar,255}}, > ???? {"status_desc",{sql_wvarchar,255}}, > ???? {"parameter",{sql_wvarchar,255}}, > ???? {"cause",{sql_wvarchar,255}}, > ???? {"disabled",sql_tinyint}]} > > I found that the macro SQL_WVARCHAR is defined in sqlucode.h. > > 2011/5/3 Ingela Andin >> >> Hi! >> >> Interesting what does odbc:describe_table/2 return on >> R14B02 ? >> >> Regards Ingela Erlang/OTP team - Ericsson AB >> >> >> 2011/5/3 Hanfei Shen : >> > Hi, >> > >> > Well it works on R14B02... >> > >> > 2011/5/3 Hanfei Shen >> >> >> >> Hi, >> >> >> >> The same on my windows 7 32 bit workstation. >> >> >> >> Erlang R13B02 (erts-5.7.3) >> >> >> >> 4> code:which(odbc). >> >> "d:/PROGRA~1/ERL57~1.3/lib/odbc-2.10.5/ebin/odbc.beam" >> >> >> >> mysql odbc 5.1.8 >> >> >> >> >> >> >> >> I'm downloading the latest version of erlang (R14B02)... >> >> >> >> >> >> 2011/5/3 Hanfei Shen >> >>> >> >>> Hi, >> >>> >> >>> I had set up a fresh system and reproduce this problem successfully. >> >>> Here is something about my installations: >> >>> >> >>> vm: >> >>> VirtualBox 4.0.6 r71416 >> >>> >> >>> gentoo: >> >>> livecd: install-amd64-minimal-20110317.iso >> >>> stage: stage3-amd64-20110428.tar.bz2 >> >>> portage: portage-20110424.tar.bz2 >> >>> >> >>> I only installed: >> >>> >> >>> dev-db/mysql-5.1.51 >> >>> dev-db/myodbc-5.1.6 >> >>> dev-lang/erlang-13.2.4 USE="kpoll odbc smp" >> >>> >> >>> table schema: >> >>> >> >>> CREATE TABLE `action` ( >> >>> ? `id` int(11) NOT NULL AUTO_INCREMENT, >> >>> ? `code` varchar(255) NOT NULL, >> >>> ? `compliment_desc` varchar(255) NOT NULL DEFAULT '', >> >>> ? `status_desc` varchar(255) NOT NULL DEFAULT '', >> >>> ? `parameter` varchar(255) NOT NULL DEFAULT '', >> >>> ? `cause` varchar(255) NOT NULL DEFAULT '', >> >>> ? `disabled` tinyint(1) NOT NULL DEFAULT '0', >> >>> ? PRIMARY KEY (`id`), >> >>> ? UNIQUE KEY `index_action_on_cause` (`cause`) >> >>> ) ENGINE=InnoDB AUTO_INCREMENT=56 DEFAULT CHARSET=utf8; >> >>> >> >>> >> >>>> I see you are running on a 64 bit ?platform, maybe you can try ?it >> >>>> also >> >>>> on a 32 bit platform. ?Maybe >> >>>> you could try accessing the database from windows using the windows >> >>>> my-sql driver. >> >>> >> >>> I reproduced the problem on a 32bit server just right now... >> >>> >> >>> I'll try it on a windows machine asap. >> >>> >> >>> 2011/5/3 Hanfei Shen : >> >>> > Hi, >> >>> > >> >>> > Hmmmmmm... The unixODBC is already in my system, but I don't know >> >>> > how >> >>> > to use it... >> >>> > >> >>> > I will setup a vm with fresh system tomorrow to reproduce the >> >>> > problem... >> >>> > >> >>> > PS, could you figure out a name of ANOTHER ODBC-DRIVER which you >> >>> > mentioned? >> >>> > >> >>> > 2011/5/3 Hanfei Shen : >> >>> >> Hi, >> >>> >> >> >>> >> I've tried https://github.com/dizzyd/erlang-mysql-driver, it works. >> >>> >> >> >>> >> I'm installing unixodbc... Wait a minute. Thnx... >> >>> >> >> >>> >> >> >>> >> 2011/5/3 Ingela Andin : >> >>> >>> Hi! >> >>> >>> >> >>> >>> Well the best thing would be if you can provide me with a way to >> >>> >>> reproduce it. >> >>> >>> Do you have the possibility to try another odbc-driver with your >> >>> >>> database? >> >>> >>> >> >>> >>> Regards Ingela Erlang/OTP team - Ericsson AB >> >>> >>> >> >>> >>> >> >>> >>> 2011/5/2 Hanfei Shen : >> >>> >>>> Hi, >> >>> >>>> >> >>> >>>> I had changed the type from SQLINTEGER to SQLSMALLINT, but the >> >>> >>>> problem >> >>> >>>> is still there... >> >>> >>>> >> >>> >>>> (gdb) i func encode_data_type >> >>> >>>> File odbcserver.c: >> >>> >>>> static void encode_data_type(SQLSMALLINT, SQLINTEGER, >> >>> >>>> SQLSMALLINT, >> >>> >>>> db_state *); >> >>> >>>> >> >>> >>>> Breakpoint 1, encode_data_type (sql_type=-9, size=255, >> >>> >>>> decimal_digits=0, state=0x7fffa5380210) at odbcserver.c:1396 >> >>> >>>> 1396 ? ? ? ?switch(sql_type) { >> >>> >>>> >> >>> >>>> Do you need any details? >> >>> >>>> >> >>> >>>> 2011/5/2 Ingela Anderton Andin : >> >>> >>>>> Hi! >> >>> >>>>> >> >>> >>>>> Hanfei Shen wrote: >> >>> >>>>>> >> >>> >>>>>> Hi Ingela, >> >>> >>>>>> >> >>> >>>>>> Did you mean the value of variable "sql_type"? >> >>> >>>>>> >> >>> >>>>>> >> >>> >>>>> >> >>> >>>>> Yes. >> >>> >>>>> >> >>> >>>>>> I tried to inspect it through gdb, setting a break on func >> >>> >>>>>> encode_data_type. And then I got: >> >>> >>>>>> >> >>> >>>>>> Breakpoint 1, encode_data_type (sql_type=-9, size=255, >> >>> >>>>>> decimal_digits=0, state=0x7fffc657ec40) at odbcserver.c:1396 >> >>> >>>>>> 1396 ? ? ? ?switch(sql_type) { >> >>> >>>>>> >> >>> >>>>>> >> >>> >>>>> >> >>> >>>>> Well that is defenetly not a good value. Looking at the code >> >>> >>>>> just >> >>> >>>>> now >> >>> >>>>> I noticed that >> >>> >>>>> >> >>> >>>>> encode_data_type defines sql_type as "SQLINTEGER sql_type" and >> >>> >>>>> it >> >>> >>>>> ought to be "SQLSMALLINT sql_type". If you change that does it >> >>> >>>>> fix >> >>> >>>>> your >> >>> >>>>> problem? >> >>> >>>>> >> >>> >>>>> Regards Ingela Erlang/OTP team - Ericsson AB >> >>> >>>>> >> >>> >>>>> >> >>> >>>>> >> >>> >>>>>> 2011/5/2 Ingela Andin : >> >>> >>>>>> >> >>> >>>>>>> >> >>> >>>>>>> Hi! >> >>> >>>>>>> >> >>> >>>>>>> The erlang odbc application supports {sql-varchars, ?N} where >> >>> >>>>>>> N = >> >>> >>>>>>> 255 >> >>> >>>>>>> in your case. The return values >> >>> >>>>>>> you get suggest that the odbc-driver you have returns an >> >>> >>>>>>> unexpected >> >>> >>>>>>> column type. >> >>> >>>>>>> >> >>> >>>>>>> In the erlang odbc port program there is a switch that handles >> >>> >>>>>>> type >> >>> >>>>>>> when describing a coloumn that if we take out >> >>> >>>>>>> the handling code looks like this. >> >>> >>>>>>> >> >>> >>>>>>> switch(sql_type) { >> >>> >>>>>>> ? case SQL_CHAR: >> >>> >>>>>>> ? case SQL_VARCHAR: >> >>> >>>>>>> ? case SQL_WCHAR: >> >>> >>>>>>> ? case SQL_WVARCHAR: >> >>> >>>>>>> ? case SQL_NUMERIC: >> >>> >>>>>>> ? case SQL_DECIMAL: >> >>> >>>>>>> ? case SQL_INTEGER: >> >>> >>>>>>> ? case SQL_TINYINT: >> >>> >>>>>>> ? case SQL_SMALLINT: >> >>> >>>>>>> ? case SQL_REAL: >> >>> >>>>>>> ? case SQL_FLOAT: >> >>> >>>>>>> ? case SQL_DOUBLE: >> >>> >>>>>>> ? case SQL_BIT: >> >>> >>>>>>> ? case SQL_TYPE_DATE: >> >>> >>>>>>> ? case SQL_TYPE_TIME: >> >>> >>>>>>> ? case SQL_TYPE_TIMESTAMP: >> >>> >>>>>>> ? case SQL_BIGINT: >> >>> >>>>>>> ? case SQL_BINARY: >> >>> >>>>>>> ? case SQL_LONGVARCHAR: >> >>> >>>>>>> ? case SQL_VARBINARY: >> >>> >>>>>>> ? case SQL_LONGVARBINARY: >> >>> >>>>>>> ? case SQL_INTERVAL_MONTH: >> >>> >>>>>>> ? case SQL_INTERVAL_YEAR: >> >>> >>>>>>> ? case SQL_INTERVAL_DAY: >> >>> >>>>>>> ? case SQL_INTERVAL_MINUTE: >> >>> >>>>>>> ? case SQL_INTERVAL_HOUR_TO_SECOND: >> >>> >>>>>>> ? case SQL_INTERVAL_MINUTE_TO_SECOND: >> >>> >>>>>>> ? case SQL_UNKNOWN_TYPE: >> >>> >>>>>>> ? default: /* Will probably never happen */ >> >>> >>>>>>> ? ? ? ei_x_encode_atom(&dynamic_buffer(state), >> >>> >>>>>>> "ODBC_UNSUPPORTED_TYPE"); >> >>> >>>>>>> ? ? ? break; >> >>> >>>>>>> ? } >> >>> >>>>>>> >> >>> >>>>>>> >> >>> >>>>>>> And you end up in the default clause which is very unexpected >> >>> >>>>>>> and >> >>> >>>>>>> the >> >>> >>>>>>> root to your problem. ?If ?you can figur out >> >>> >>>>>>> what your driver returns for the ODBC C-API function >> >>> >>>>>>> SQLDescribeCol we >> >>> >>>>>>> could know if the driver is at fault or if the odbc-port >> >>> >>>>>>> program >> >>> >>>>>>> is. >> >>> >>>>>>> >> >>> >>>>>>> Regards ?Ingela Erlang/OTP team - Ericsson AB >> >>> >>>>>>> >> >>> >>>>>>> 2011/5/1 Hanfei Shen : >> >>> >>>>>>> >> >>> >>>>>>>> >> >>> >>>>>>>> Dear all, >> >>> >>>>>>>> >> >>> >>>>>>>> I'm a newbie programming in erlang. When I used ODBC to >> >>> >>>>>>>> connect >> >>> >>>>>>>> to a >> >>> >>>>>>>> MySQL database through Connector/ODBC (MyODBC), I got some >> >>> >>>>>>>> error >> >>> >>>>>>>> when >> >>> >>>>>>>> calling odbc:sql_query(Conn, "SELECT * FROM action"): >> >>> >>>>>>>> >> >>> >>>>>>>> {error,"Column type not supported"} >> >>> >>>>>>>> >> >>> >>>>>>>> Then I call odbc:describe_table(Conn, "action"), it returned: >> >>> >>>>>>>> >> >>> >>>>>>>> {ok,[{"id",sql_integer}, >> >>> >>>>>>>> ? ? {"code",'ODBC_UNSUPPORTED_TYPE'}, >> >>> >>>>>>>> ? ? {"compliment_desc",'ODBC_UNSUPPORTED_TYPE'}, >> >>> >>>>>>>> ? ? {"status_desc",'ODBC_UNSUPPORTED_TYPE'}, >> >>> >>>>>>>> ? ? {"parameter",'ODBC_UNSUPPORTED_TYPE'}, >> >>> >>>>>>>> ? ? {"cause",'ODBC_UNSUPPORTED_TYPE'}, >> >>> >>>>>>>> ? ? {"disabled",sql_tinyint}]} >> >>> >>>>>>>> >> >>> >>>>>>>> And desc the table in mysql client: >> >>> >>>>>>>> mysql> desc action; >> >>> >>>>>>>> >> >>> >>>>>>>> >> >>> >>>>>>>> >> >>> >>>>>>>> +-----------------+--------------+------+-----+---------+----------------+ >> >>> >>>>>>>> | Field ? ? ? ? ? | Type ? ? ? ? | Null | Key | Default | >> >>> >>>>>>>> Extra >> >>> >>>>>>>> ?| >> >>> >>>>>>>> >> >>> >>>>>>>> >> >>> >>>>>>>> >> >>> >>>>>>>> +-----------------+--------------+------+-----+---------+----------------+ >> >>> >>>>>>>> | id ? ? ? ? ? ? ?| int(11) ? ? ?| NO ? | PRI | NULL ? ?| >> >>> >>>>>>>> auto_increment >> >>> >>>>>>>> | >> >>> >>>>>>>> | code ? ? ? ? ? ?| varchar(255) | NO ? | ? ? | NULL ? ?| >> >>> >>>>>>>> ?| >> >>> >>>>>>>> | compliment_desc | varchar(255) | NO ? | ? ? | ? ? ? ? | >> >>> >>>>>>>> ?| >> >>> >>>>>>>> | status_desc ? ? | varchar(255) | NO ? | ? ? | ? ? ? ? | >> >>> >>>>>>>> ?| >> >>> >>>>>>>> | parameter ? ? ? | varchar(255) | NO ? | ? ? | ? ? ? ? | >> >>> >>>>>>>> ?| >> >>> >>>>>>>> | cause ? ? ? ? ? | varchar(255) | NO ? | UNI | ? ? ? ? | >> >>> >>>>>>>> ?| >> >>> >>>>>>>> | disabled ? ? ? ?| tinyint(1) ? | NO ? | ? ? | 0 ? ? ? | >> >>> >>>>>>>> ?| >> >>> >>>>>>>> >> >>> >>>>>>>> >> >>> >>>>>>>> >> >>> >>>>>>>> +-----------------+--------------+------+-----+---------+----------------+ >> >>> >>>>>>>> >> >>> >>>>>>>> It seems that Erlang ODBC driver does not support the mysql >> >>> >>>>>>>> type >> >>> >>>>>>>> varchar? How can I use the database without touching the db >> >>> >>>>>>>> schema? >> >>> >>>>>>>> >> >>> >>>>>>>> >> >>> >>>>>>>> Some details about the system env: >> >>> >>>>>>>> >> >>> >>>>>>>> $ uname -a >> >>> >>>>>>>> Linux 2.6.36-gentoo-r8 #4 SMP Thu Apr 7 20:13:18 CST 2011 >> >>> >>>>>>>> x86_64 >> >>> >>>>>>>> Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz GenuineIntel >> >>> >>>>>>>> GNU/Linux >> >>> >>>>>>>> >> >>> >>>>>>>> $ erl >> >>> >>>>>>>> Erlang R13B04 (erts-5.7.5) [source] [64-bit] [smp:2:2] [rq:2] >> >>> >>>>>>>> [async-threads:0] [kernel-poll:false] >> >>> >>>>>>>> >> >>> >>>>>>>> $ emerge -vp erlang >> >>> >>>>>>>> dev-lang/erlang-13.2.4 ?USE="doc kpoll odbc smp ssl -emacs >> >>> >>>>>>>> -hipe >> >>> >>>>>>>> -java >> >>> >>>>>>>> -sctp -tk -wxwidgets" >> >>> >>>>>>>> >> >>> >>>>>>>> eshell> code:which(odbc). >> >>> >>>>>>>> "/usr/lib64/erlang/lib/odbc-2.10.7/ebin/odbc.beam" >> >>> >>>>>>>> >> >>> >>>>>>>> $ mysql -V >> >>> >>>>>>>> mysql ?Ver 14.14 Distrib 5.1.51, for pc-linux-gnu (x86_64) >> >>> >>>>>>>> using >> >>> >>>>>>>> readline 5.1 >> >>> >>>>>>>> >> >>> >>>>>>>> Server version: 5.1.51-log Gentoo Linux mysql-5.1.51 >> >>> >>>>>>>> >> >>> >>>>>>>> $ emerge -vp myodbc >> >>> >>>>>>>> dev-db/myodbc-5.1.6 ?USE="-debug -doc -qt4 -static" >> >>> >>>>>>>> >> >>> >>>>>>>> >> >>> >>>>>>>> Any help will be greatly appreciated. ?Thanks in advance. >> >>> >>>>>>>> Sorry for my poor English, I'm not a native... >> >>> >>>>>>>> >> >>> >>>>>>>> Best, >> >>> >>>>>>>> >> >>> >>>>>>>> -- >> >>> >>>>>>>> Hanfei >> >>> >>>>>>>> _______________________________________________ >> >>> >>>>>>>> erlang-questions mailing list >> >>> >>>>>>>> erlang-questions@REDACTED >> >>> >>>>>>>> http://erlang.org/mailman/listinfo/erlang-questions >> >>> >>>>>>>> >> >>> >>>>>>>> >> >>> >>>>>> >> >>> >>>>>> >> >>> >>>>> >> >>> >>>>> >> >>> >>>> _______________________________________________ >> >>> >>>> erlang-questions mailing list >> >>> >>>> erlang-questions@REDACTED >> >>> >>>> http://erlang.org/mailman/listinfo/erlang-questions >> >>> >>>> >> >>> >>> >> >>> >> >> >>> > >> >>> >> >> >> > >> > >> > _______________________________________________ >> > erlang-questions mailing list >> > erlang-questions@REDACTED >> > http://erlang.org/mailman/listinfo/erlang-questions >> > >> > > > From nick@REDACTED Tue May 3 17:13:57 2011 From: nick@REDACTED (Niclas Eklund) Date: Tue, 3 May 2011 17:13:57 +0200 Subject: [erlang-questions] Errors when generating tests for CosNotifications on windows. In-Reply-To: References: Message-ID: Hello again! Two questions: * Are you using a fairly new version of cygwin? * Do you use the boostrap compiler (erlc) or the "proper" one? If it's the bootstrap compiler it should work if you switch to the other one. Best Regards, Niclas @ Erlang/OTP On Tue, 3 May 2011, Niclas Eklund wrote: > > Hello! > > As you've probably guessed we don't encounter this problem. ;-) But then the > test suites are only built once (not a Windows machine) and then re-used by > different plattforms. Speed things up. > > Since there is a 256 chars limit (Windows paths and command line), this might > be it. I suppose that a faulty setting of one of the Erlang related > environment variables (e.g. ERL_TOP) could cause problems as well. Perhaps > you can e-mail them to me? > > Due to the fact that CosNotification depends on several other Cos-services, > more IDL files needs to be included compared with, for example, CosTime. > > Best Regards, > > Niclas @ Erlang/OTP > > On Thu, 21 Apr 2011, Fredrik Andersson wrote: > >> On Thu, Apr 21, 2011 at 11:04 AM, Alexander Krasnukhin < >> the.malkolm@REDACTED> wrote: >> >>> Hi, >>> >>> It is just a guess and probably sounds stupid but could you try to compile >>> within the folder with smaller path length? >>> >> >> I tried moving the otp folder to / and it had no difference, I can make >> them >> all compile if I cp the idl files to the test folder of cosNotification but >> that seems to be a suboptimal way of doing things. >> >> >>> >>> On Thu, Apr 21, 2011 at 10:57 AM, Fredrik Andersson >>> wrote: >>> >>>> Hi all >>>> >>>> I want to run the test suites on my windows build but I am running into >>>> trouble when generating the tests for CosNotification. I can reproduce >>>> the >>>> error by building the tests inside of otp/lib/CosNotification/test using >>>> make tests. >>>> >>>> Can anyone help? >>>> >>>> The following is the error I get. I have verified that the idl files are >>>> present in the src directory. >>>> >>>> erlc +debug_info -pa >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosNotification/ebin -pa >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosNotification/src -pa >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosTime/ebin -pa >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosTime/include -pa >>>> /home/ESLbingen/bingen/tmp/otp/lib/orber/ebin -pa >>>> /home/ESLbingen/bingen/tmp/otp/lib/ic/ebin -pa >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosNotification/include >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosEvent/src >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosNotification/include -pa >>>> /home/ESLbingen/bingen/tmp/otp/lib/orber/include -pa >>>> /home/ESLbingen/bingen/tmp/otp/internal_tools/test_server/ebin -pa >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosNotification/ebin -pa >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosNotification/test/idl_output -pa >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosTime/ebin -pa >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosTime/include -pa >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosNotification/include -pa >>>> /home/ESLbingen/bingen/tmp/otp/lib/ic/ebin >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosTime/ebin >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosTime/include >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/orber/include >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosNotification/src >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosNotification/include >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosNotification >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosNotification/test/idl_output >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/test_server/include -oidl_output \ >>>> +'{cfgfile,"notify_test_server.cfg"}' >>>> notify_test_server.idl >>>> []: warning: unrecognised option: debug_info >>>> Erlang IDL compiler version 4.2.26 >>>> "c:/cygwin/home/ESLBIN~1/bingen/tmp/otp/lib/COSNOT~1/test/notify_test_server.idl": >>>> preprocessor error: >>>> c:/cygwin/home/ESLBIN~1/bingen/tmp/otp/lib/COSNOT~1/test/notify_test_server.idl:23: >>>> CosNotification.idl: No such file or directory >>>> "c:/cygwin/home/ESLBIN~1/bingen/tmp/otp/lib/COSNOT~1/test/notify_test_server.idl": >>>> preprocessor error: >>>> c:/cygwin/home/ESLBIN~1/bingen/tmp/otp/lib/COSNOT~1/test/notify_test_server.idl:24: >>>> CosNotifyComm.idl: No such file or directory >>>> "c:/cygwin/home/ESLBIN~1/bingen/tmp/otp/lib/COSNOT~1/test/notify_test_server.idl": >>>> 2 errors found >>>> >>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>>> >>> >>> >>> -- >>> Regards, >>> Alexander >>> >>> >> > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From qqshfox@REDACTED Tue May 3 19:07:46 2011 From: qqshfox@REDACTED (Hanfei Shen) Date: Wed, 4 May 2011 01:07:46 +0800 Subject: [erlang-questions] Erlang and MySQL: ODBC, Column type not supported In-Reply-To: References: <4DBE7B49.1080505@erix.ericsson.se> Message-ID: Hi, It does solve THIS problem, but not all... :( Briefly, it does not support the mysql column type TEXT (the unicode one). So I made a patch to solve the unicode TEXT problem. Thanks to Juhani R?nkimies, most of hard work has been done by him, I just add some lines to the file odbcserver.c and it works well for me. Here is my git repository: git://github.com/qqshfox/otp.git and branch: odbc_sql_wlongvarchar_support This is the first time I submit a patch to a open source project, I'd greatly appreciate if you could kindly review my code. :) 2011/5/3 Ingela Andin > Hi! > > Ok problem solved then, from the releasenotes of odbc version 2.10.8: > > "1.3 ODBC 2.10.8 > Improvements and New Features > > * > > ODBC now handles the types SQL_WCHAR and SQL_WVARCHAR. Thanks to > Juhani R?nkimies. ODBC also has a new connection option to return all > strings as binaries and also expect strings to be binaries in the > param_query function. These changes provides some unicode support. > > Own Id: OTP-7452" > > > You had version 2.10.7 and latest version (in R14B02) is 2.10.10. > > Regards Ingela Erlang/OTP team - Ericsson AB > > > 2011/5/3 Hanfei Shen : > > Hi, > > > > It returns: > > > > {ok,[{"id",sql_integer}, > > {"code",{sql_wvarchar,255}}, > > {"compliment_desc",{sql_wvarchar,255}}, > > {"status_desc",{sql_wvarchar,255}}, > > {"parameter",{sql_wvarchar,255}}, > > {"cause",{sql_wvarchar,255}}, > > {"disabled",sql_tinyint}]} > > > > I found that the macro SQL_WVARCHAR is defined in sqlucode.h. > > > > 2011/5/3 Ingela Andin > >> > >> Hi! > >> > >> Interesting what does odbc:describe_table/2 return on > >> R14B02 ? > >> > >> Regards Ingela Erlang/OTP team - Ericsson AB > >> > >> > >> 2011/5/3 Hanfei Shen : > >> > Hi, > >> > > >> > Well it works on R14B02... > >> > > >> > 2011/5/3 Hanfei Shen > >> >> > >> >> Hi, > >> >> > >> >> The same on my windows 7 32 bit workstation. > >> >> > >> >> Erlang R13B02 (erts-5.7.3) > >> >> > >> >> 4> code:which(odbc). > >> >> "d:/PROGRA~1/ERL57~1.3/lib/odbc-2.10.5/ebin/odbc.beam" > >> >> > >> >> mysql odbc 5.1.8 > >> >> > >> >> > >> >> > >> >> I'm downloading the latest version of erlang (R14B02)... > >> >> > >> >> > >> >> 2011/5/3 Hanfei Shen > >> >>> > >> >>> Hi, > >> >>> > >> >>> I had set up a fresh system and reproduce this problem successfully. > >> >>> Here is something about my installations: > >> >>> > >> >>> vm: > >> >>> VirtualBox 4.0.6 r71416 > >> >>> > >> >>> gentoo: > >> >>> livecd: install-amd64-minimal-20110317.iso > >> >>> stage: stage3-amd64-20110428.tar.bz2 > >> >>> portage: portage-20110424.tar.bz2 > >> >>> > >> >>> I only installed: > >> >>> > >> >>> dev-db/mysql-5.1.51 > >> >>> dev-db/myodbc-5.1.6 > >> >>> dev-lang/erlang-13.2.4 USE="kpoll odbc smp" > >> >>> > >> >>> table schema: > >> >>> > >> >>> CREATE TABLE `action` ( > >> >>> `id` int(11) NOT NULL AUTO_INCREMENT, > >> >>> `code` varchar(255) NOT NULL, > >> >>> `compliment_desc` varchar(255) NOT NULL DEFAULT '', > >> >>> `status_desc` varchar(255) NOT NULL DEFAULT '', > >> >>> `parameter` varchar(255) NOT NULL DEFAULT '', > >> >>> `cause` varchar(255) NOT NULL DEFAULT '', > >> >>> `disabled` tinyint(1) NOT NULL DEFAULT '0', > >> >>> PRIMARY KEY (`id`), > >> >>> UNIQUE KEY `index_action_on_cause` (`cause`) > >> >>> ) ENGINE=InnoDB AUTO_INCREMENT=56 DEFAULT CHARSET=utf8; > >> >>> > >> >>> > >> >>>> I see you are running on a 64 bit platform, maybe you can try it > >> >>>> also > >> >>>> on a 32 bit platform. Maybe > >> >>>> you could try accessing the database from windows using the windows > >> >>>> my-sql driver. > >> >>> > >> >>> I reproduced the problem on a 32bit server just right now... > >> >>> > >> >>> I'll try it on a windows machine asap. > >> >>> > >> >>> 2011/5/3 Hanfei Shen : > >> >>> > Hi, > >> >>> > > >> >>> > Hmmmmmm... The unixODBC is already in my system, but I don't know > >> >>> > how > >> >>> > to use it... > >> >>> > > >> >>> > I will setup a vm with fresh system tomorrow to reproduce the > >> >>> > problem... > >> >>> > > >> >>> > PS, could you figure out a name of ANOTHER ODBC-DRIVER which you > >> >>> > mentioned? > >> >>> > > >> >>> > 2011/5/3 Hanfei Shen : > >> >>> >> Hi, > >> >>> >> > >> >>> >> I've tried https://github.com/dizzyd/erlang-mysql-driver, it > works. > >> >>> >> > >> >>> >> I'm installing unixodbc... Wait a minute. Thnx... > >> >>> >> > >> >>> >> > >> >>> >> 2011/5/3 Ingela Andin : > >> >>> >>> Hi! > >> >>> >>> > >> >>> >>> Well the best thing would be if you can provide me with a way to > >> >>> >>> reproduce it. > >> >>> >>> Do you have the possibility to try another odbc-driver with your > >> >>> >>> database? > >> >>> >>> > >> >>> >>> Regards Ingela Erlang/OTP team - Ericsson AB > >> >>> >>> > >> >>> >>> > >> >>> >>> 2011/5/2 Hanfei Shen : > >> >>> >>>> Hi, > >> >>> >>>> > >> >>> >>>> I had changed the type from SQLINTEGER to SQLSMALLINT, but the > >> >>> >>>> problem > >> >>> >>>> is still there... > >> >>> >>>> > >> >>> >>>> (gdb) i func encode_data_type > >> >>> >>>> File odbcserver.c: > >> >>> >>>> static void encode_data_type(SQLSMALLINT, SQLINTEGER, > >> >>> >>>> SQLSMALLINT, > >> >>> >>>> db_state *); > >> >>> >>>> > >> >>> >>>> Breakpoint 1, encode_data_type (sql_type=-9, size=255, > >> >>> >>>> decimal_digits=0, state=0x7fffa5380210) at odbcserver.c:1396 > >> >>> >>>> 1396 switch(sql_type) { > >> >>> >>>> > >> >>> >>>> Do you need any details? > >> >>> >>>> > >> >>> >>>> 2011/5/2 Ingela Anderton Andin : > >> >>> >>>>> Hi! > >> >>> >>>>> > >> >>> >>>>> Hanfei Shen wrote: > >> >>> >>>>>> > >> >>> >>>>>> Hi Ingela, > >> >>> >>>>>> > >> >>> >>>>>> Did you mean the value of variable "sql_type"? > >> >>> >>>>>> > >> >>> >>>>>> > >> >>> >>>>> > >> >>> >>>>> Yes. > >> >>> >>>>> > >> >>> >>>>>> I tried to inspect it through gdb, setting a break on func > >> >>> >>>>>> encode_data_type. And then I got: > >> >>> >>>>>> > >> >>> >>>>>> Breakpoint 1, encode_data_type (sql_type=-9, size=255, > >> >>> >>>>>> decimal_digits=0, state=0x7fffc657ec40) at odbcserver.c:1396 > >> >>> >>>>>> 1396 switch(sql_type) { > >> >>> >>>>>> > >> >>> >>>>>> > >> >>> >>>>> > >> >>> >>>>> Well that is defenetly not a good value. Looking at the code > >> >>> >>>>> just > >> >>> >>>>> now > >> >>> >>>>> I noticed that > >> >>> >>>>> > >> >>> >>>>> encode_data_type defines sql_type as "SQLINTEGER sql_type" and > >> >>> >>>>> it > >> >>> >>>>> ought to be "SQLSMALLINT sql_type". If you change that does it > >> >>> >>>>> fix > >> >>> >>>>> your > >> >>> >>>>> problem? > >> >>> >>>>> > >> >>> >>>>> Regards Ingela Erlang/OTP team - Ericsson AB > >> >>> >>>>> > >> >>> >>>>> > >> >>> >>>>> > >> >>> >>>>>> 2011/5/2 Ingela Andin : > >> >>> >>>>>> > >> >>> >>>>>>> > >> >>> >>>>>>> Hi! > >> >>> >>>>>>> > >> >>> >>>>>>> The erlang odbc application supports {sql-varchars, N} > where > >> >>> >>>>>>> N = > >> >>> >>>>>>> 255 > >> >>> >>>>>>> in your case. The return values > >> >>> >>>>>>> you get suggest that the odbc-driver you have returns an > >> >>> >>>>>>> unexpected > >> >>> >>>>>>> column type. > >> >>> >>>>>>> > >> >>> >>>>>>> In the erlang odbc port program there is a switch that > handles > >> >>> >>>>>>> type > >> >>> >>>>>>> when describing a coloumn that if we take out > >> >>> >>>>>>> the handling code looks like this. > >> >>> >>>>>>> > >> >>> >>>>>>> switch(sql_type) { > >> >>> >>>>>>> case SQL_CHAR: > >> >>> >>>>>>> case SQL_VARCHAR: > >> >>> >>>>>>> case SQL_WCHAR: > >> >>> >>>>>>> case SQL_WVARCHAR: > >> >>> >>>>>>> case SQL_NUMERIC: > >> >>> >>>>>>> case SQL_DECIMAL: > >> >>> >>>>>>> case SQL_INTEGER: > >> >>> >>>>>>> case SQL_TINYINT: > >> >>> >>>>>>> case SQL_SMALLINT: > >> >>> >>>>>>> case SQL_REAL: > >> >>> >>>>>>> case SQL_FLOAT: > >> >>> >>>>>>> case SQL_DOUBLE: > >> >>> >>>>>>> case SQL_BIT: > >> >>> >>>>>>> case SQL_TYPE_DATE: > >> >>> >>>>>>> case SQL_TYPE_TIME: > >> >>> >>>>>>> case SQL_TYPE_TIMESTAMP: > >> >>> >>>>>>> case SQL_BIGINT: > >> >>> >>>>>>> case SQL_BINARY: > >> >>> >>>>>>> case SQL_LONGVARCHAR: > >> >>> >>>>>>> case SQL_VARBINARY: > >> >>> >>>>>>> case SQL_LONGVARBINARY: > >> >>> >>>>>>> case SQL_INTERVAL_MONTH: > >> >>> >>>>>>> case SQL_INTERVAL_YEAR: > >> >>> >>>>>>> case SQL_INTERVAL_DAY: > >> >>> >>>>>>> case SQL_INTERVAL_MINUTE: > >> >>> >>>>>>> case SQL_INTERVAL_HOUR_TO_SECOND: > >> >>> >>>>>>> case SQL_INTERVAL_MINUTE_TO_SECOND: > >> >>> >>>>>>> case SQL_UNKNOWN_TYPE: > >> >>> >>>>>>> default: /* Will probably never happen */ > >> >>> >>>>>>> ei_x_encode_atom(&dynamic_buffer(state), > >> >>> >>>>>>> "ODBC_UNSUPPORTED_TYPE"); > >> >>> >>>>>>> break; > >> >>> >>>>>>> } > >> >>> >>>>>>> > >> >>> >>>>>>> > >> >>> >>>>>>> And you end up in the default clause which is very > unexpected > >> >>> >>>>>>> and > >> >>> >>>>>>> the > >> >>> >>>>>>> root to your problem. If you can figur out > >> >>> >>>>>>> what your driver returns for the ODBC C-API function > >> >>> >>>>>>> SQLDescribeCol we > >> >>> >>>>>>> could know if the driver is at fault or if the odbc-port > >> >>> >>>>>>> program > >> >>> >>>>>>> is. > >> >>> >>>>>>> > >> >>> >>>>>>> Regards Ingela Erlang/OTP team - Ericsson AB > >> >>> >>>>>>> > >> >>> >>>>>>> 2011/5/1 Hanfei Shen : > >> >>> >>>>>>> > >> >>> >>>>>>>> > >> >>> >>>>>>>> Dear all, > >> >>> >>>>>>>> > >> >>> >>>>>>>> I'm a newbie programming in erlang. When I used ODBC to > >> >>> >>>>>>>> connect > >> >>> >>>>>>>> to a > >> >>> >>>>>>>> MySQL database through Connector/ODBC (MyODBC), I got some > >> >>> >>>>>>>> error > >> >>> >>>>>>>> when > >> >>> >>>>>>>> calling odbc:sql_query(Conn, "SELECT * FROM action"): > >> >>> >>>>>>>> > >> >>> >>>>>>>> {error,"Column type not supported"} > >> >>> >>>>>>>> > >> >>> >>>>>>>> Then I call odbc:describe_table(Conn, "action"), it > returned: > >> >>> >>>>>>>> > >> >>> >>>>>>>> {ok,[{"id",sql_integer}, > >> >>> >>>>>>>> {"code",'ODBC_UNSUPPORTED_TYPE'}, > >> >>> >>>>>>>> {"compliment_desc",'ODBC_UNSUPPORTED_TYPE'}, > >> >>> >>>>>>>> {"status_desc",'ODBC_UNSUPPORTED_TYPE'}, > >> >>> >>>>>>>> {"parameter",'ODBC_UNSUPPORTED_TYPE'}, > >> >>> >>>>>>>> {"cause",'ODBC_UNSUPPORTED_TYPE'}, > >> >>> >>>>>>>> {"disabled",sql_tinyint}]} > >> >>> >>>>>>>> > >> >>> >>>>>>>> And desc the table in mysql client: > >> >>> >>>>>>>> mysql> desc action; > >> >>> >>>>>>>> > >> >>> >>>>>>>> > >> >>> >>>>>>>> > >> >>> >>>>>>>> > +-----------------+--------------+------+-----+---------+----------------+ > >> >>> >>>>>>>> | Field | Type | Null | Key | Default | > >> >>> >>>>>>>> Extra > >> >>> >>>>>>>> | > >> >>> >>>>>>>> > >> >>> >>>>>>>> > >> >>> >>>>>>>> > >> >>> >>>>>>>> > +-----------------+--------------+------+-----+---------+----------------+ > >> >>> >>>>>>>> | id | int(11) | NO | PRI | NULL | > >> >>> >>>>>>>> auto_increment > >> >>> >>>>>>>> | > >> >>> >>>>>>>> | code | varchar(255) | NO | | NULL | > >> >>> >>>>>>>> | > >> >>> >>>>>>>> | compliment_desc | varchar(255) | NO | | | > >> >>> >>>>>>>> | > >> >>> >>>>>>>> | status_desc | varchar(255) | NO | | | > >> >>> >>>>>>>> | > >> >>> >>>>>>>> | parameter | varchar(255) | NO | | | > >> >>> >>>>>>>> | > >> >>> >>>>>>>> | cause | varchar(255) | NO | UNI | | > >> >>> >>>>>>>> | > >> >>> >>>>>>>> | disabled | tinyint(1) | NO | | 0 | > >> >>> >>>>>>>> | > >> >>> >>>>>>>> > >> >>> >>>>>>>> > >> >>> >>>>>>>> > >> >>> >>>>>>>> > +-----------------+--------------+------+-----+---------+----------------+ > >> >>> >>>>>>>> > >> >>> >>>>>>>> It seems that Erlang ODBC driver does not support the mysql > >> >>> >>>>>>>> type > >> >>> >>>>>>>> varchar? How can I use the database without touching the db > >> >>> >>>>>>>> schema? > >> >>> >>>>>>>> > >> >>> >>>>>>>> > >> >>> >>>>>>>> Some details about the system env: > >> >>> >>>>>>>> > >> >>> >>>>>>>> $ uname -a > >> >>> >>>>>>>> Linux 2.6.36-gentoo-r8 #4 SMP Thu Apr 7 20:13:18 CST 2011 > >> >>> >>>>>>>> x86_64 > >> >>> >>>>>>>> Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz GenuineIntel > >> >>> >>>>>>>> GNU/Linux > >> >>> >>>>>>>> > >> >>> >>>>>>>> $ erl > >> >>> >>>>>>>> Erlang R13B04 (erts-5.7.5) [source] [64-bit] [smp:2:2] > [rq:2] > >> >>> >>>>>>>> [async-threads:0] [kernel-poll:false] > >> >>> >>>>>>>> > >> >>> >>>>>>>> $ emerge -vp erlang > >> >>> >>>>>>>> dev-lang/erlang-13.2.4 USE="doc kpoll odbc smp ssl -emacs > >> >>> >>>>>>>> -hipe > >> >>> >>>>>>>> -java > >> >>> >>>>>>>> -sctp -tk -wxwidgets" > >> >>> >>>>>>>> > >> >>> >>>>>>>> eshell> code:which(odbc). > >> >>> >>>>>>>> "/usr/lib64/erlang/lib/odbc-2.10.7/ebin/odbc.beam" > >> >>> >>>>>>>> > >> >>> >>>>>>>> $ mysql -V > >> >>> >>>>>>>> mysql Ver 14.14 Distrib 5.1.51, for pc-linux-gnu (x86_64) > >> >>> >>>>>>>> using > >> >>> >>>>>>>> readline 5.1 > >> >>> >>>>>>>> > >> >>> >>>>>>>> Server version: 5.1.51-log Gentoo Linux mysql-5.1.51 > >> >>> >>>>>>>> > >> >>> >>>>>>>> $ emerge -vp myodbc > >> >>> >>>>>>>> dev-db/myodbc-5.1.6 USE="-debug -doc -qt4 -static" > >> >>> >>>>>>>> > >> >>> >>>>>>>> > >> >>> >>>>>>>> Any help will be greatly appreciated. Thanks in advance. > >> >>> >>>>>>>> Sorry for my poor English, I'm not a native... > >> >>> >>>>>>>> > >> >>> >>>>>>>> Best, > >> >>> >>>>>>>> > >> >>> >>>>>>>> -- > >> >>> >>>>>>>> Hanfei > >> >>> >>>>>>>> _______________________________________________ > >> >>> >>>>>>>> erlang-questions mailing list > >> >>> >>>>>>>> erlang-questions@REDACTED > >> >>> >>>>>>>> http://erlang.org/mailman/listinfo/erlang-questions > >> >>> >>>>>>>> > >> >>> >>>>>>>> > >> >>> >>>>>> > >> >>> >>>>>> > >> >>> >>>>> > >> >>> >>>>> > >> >>> >>>> _______________________________________________ > >> >>> >>>> erlang-questions mailing list > >> >>> >>>> erlang-questions@REDACTED > >> >>> >>>> http://erlang.org/mailman/listinfo/erlang-questions > >> >>> >>>> > >> >>> >>> > >> >>> >> > >> >>> > > >> >>> > >> >> > >> > > >> > > >> > _______________________________________________ > >> > erlang-questions mailing list > >> > erlang-questions@REDACTED > >> > http://erlang.org/mailman/listinfo/erlang-questions > >> > > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From als@REDACTED Tue May 3 21:33:58 2011 From: als@REDACTED (Anthony Shipman) Date: Wed, 4 May 2011 05:33:58 +1000 Subject: [erlang-questions] byte() vs. char() use in documentation In-Reply-To: <20110503094549.GA10981@erix.ericsson.se> References: <20110502091415.GA6512@erix.ericsson.se> <20110503094549.GA10981@erix.ericsson.se> Message-ID: <201105040533.58985.als@iinet.net.au> On Tue, 3 May 2011 07:45:49 pm Raimo Niskanen wrote: > The programmer should regard strings as a sequence of unicode code points. > As such they are just that and there is no encoding to bother about. > The code point number uniquely defines which unicode character it is. As I recall, a Unicode character can be composed of up to 7 code points. To quote a text book I'm looking at now: ------------- The trick is, again, to disabuse yourself of the idea that a one-to-one correspondence exists between "characters" as the user is used to thinking of them and code points (or code units) in the backing store. Unicode uses the term "character" to mean more or less "the entity that's represented by a single Unicode code point," but this concept doesn't always match the user's definition of "character". ------------- I think a more complete design would represent a character as a binary that is a UTF8 encoding of its code points. A string would then be a deep list of these binaries. -- Anthony Shipman Mamas don't let your babies als@REDACTED grow up to be outsourced. From dmercer@REDACTED Tue May 3 22:05:24 2011 From: dmercer@REDACTED (David Mercer) Date: Tue, 3 May 2011 15:05:24 -0500 Subject: [erlang-questions] byte() vs. char() use in documentation In-Reply-To: <20110503094549.GA10981@erix.ericsson.se> References: <20110502091415.GA6512@erix.ericsson.se> <372726991.139721304328918708.JavaMail.root@zimbra> <20110502095824.GA9576@erix.ericsson.se> <4DBE83B4.50501@cs.ntua.gr> <20110503094549.GA10981@erix.ericsson.se> Message-ID: <001801cc09cd$72129d70$5637d850$@com> On Tuesday, May 03, 2011, Raimo Niskanen wrote: > I repeat again. The programmer decides what the bytes mean. The list > [0,0,16#21,16#2b] e.g would mean "angstrom sign" if the encoding is > UTF-32 big endian. And that is a valid iolist. > But [16#212b] is not. Out of curiosity, why does unicode:characters_to_binary([16#212b], {utf32, big}). return the UTF-8 representation of ? (Angstrom sign) and not the big-endian UTF-32 like I expected? From dmercer@REDACTED Tue May 3 22:05:24 2011 From: dmercer@REDACTED (David Mercer) Date: Tue, 3 May 2011 15:05:24 -0500 Subject: [erlang-questions] byte() vs. char() use in documentation In-Reply-To: <201105040533.58985.als@iinet.net.au> References: <20110502091415.GA6512@erix.ericsson.se> <20110503094549.GA10981@erix.ericsson.se> <201105040533.58985.als@iinet.net.au> Message-ID: <001901cc09cd$73653520$5a2f9f60$@com> On Tuesday, May 03, 2011, Anthony Shipman wrote: > I think a more complete design would represent a character as a binary > that is > a UTF8 encoding of its code points. A string would then be a deep list > of > these binaries. How is that superior than representing a character by a single integer representing the Unicode codepoint, a string by a list of characters? You can always use unicode:characters_to_binary/1 to convert to a UTF-8 binary if you wish. From pmundkur.erlang@REDACTED Tue May 3 23:24:52 2011 From: pmundkur.erlang@REDACTED (Prashanth Mundkur) Date: Tue, 3 May 2011 14:24:52 -0700 Subject: [erlang-questions] Dialyzer questions In-Reply-To: References: Message-ID: <20110503212452.GA7410@damage.nokiapaloalto.com> On 11:02 Tue 03 May , Attila Rajmund Nohl wrote: > 2011/5/3, Prashanth Mundkur : > [...] > > We are trying to understand the following output (I hope the inline code > > pasting below comes out readable): > > > > $ cat dial.erl > > -module(dial). > > -export([abort/2, extract/2, > > diskspace/1, monitor_diskspace/2, refresh_tags/1, > > monitor_launch/0]). > > > > % We have helper functions like this: > > abort(Msg, Code) -> > > error_logger:warning_report(Msg), > > exit(Code). > > % which give rise to the following dialyzer message: > > % > > % Function abort/2 only terminates with explicit exception > > % How do we interpret this message? > > As it is written :-) The exit/1 call terminates the process, so the > function does not return. If this is what you want, you can skip this > warning. I discovered that just adding a spec specifying a no_return() makes the warning go away; that's exactly what I needed. > > % Even with a plt that includes stdlib, there is no warning for the > > % following code: > > -spec extract(binary(), nonempty_string()) -> 'ok'. > > extract(Pack, Dir) -> > > case zip:extract(Pack, [{cwd, Dir}]) of > > {ok, Files} -> > > Files; > > {error, Reason} -> > > exit({error, Reason}) > > end. > > Yes, because at least one clause does return a value. Yes, but the value it returns is not an 'ok'. Thanks, --prashanth From overminddl1@REDACTED Wed May 4 00:35:39 2011 From: overminddl1@REDACTED (OvermindDL1) Date: Tue, 3 May 2011 16:35:39 -0600 Subject: [erlang-questions] Errors when generating tests for CosNotifications on windows. In-Reply-To: References: Message-ID: On May 3, 2011 7:36 AM, "Niclas Eklund" wrote: > > > Hello! > > As you've probably guessed we don't encounter this problem. ;-) But then the test suites are only built once (not a Windows machine) and then re-used by different plattforms. Speed things up. > > Since there is a 256 chars limit (Windows paths and command line), this might be it. I suppose that a faulty setting of one of the Erlang related environment variables (e.g. ERL_TOP) could cause problems as well. Perhaps you can e-mail them to me? As I recall Windows has a limit if 4096 per complete path if using the NT api for note. 512 if 8.3 format is enabled in the registry. > > Due to the fact that CosNotification depends on several other Cos-services, more IDL files needs to be included compared with, for example, CosTime. > > Best Regards, > > Niclas @ Erlang/OTP > > > On Thu, 21 Apr 2011, Fredrik Andersson wrote: > >> On Thu, Apr 21, 2011 at 11:04 AM, Alexander Krasnukhin < >> the.malkolm@REDACTED> wrote: >> >>> Hi, >>> >>> It is just a guess and probably sounds stupid but could you try to compile >>> within the folder with smaller path length? >>> >> >> I tried moving the otp folder to / and it had no difference, I can make them >> all compile if I cp the idl files to the test folder of cosNotification but >> that seems to be a suboptimal way of doing things. >> >> >>> >>> On Thu, Apr 21, 2011 at 10:57 AM, Fredrik Andersson < sir.sedrik@REDACTED>wrote: >>> >>>> Hi all >>>> >>>> I want to run the test suites on my windows build but I am running into >>>> trouble when generating the tests for CosNotification. I can reproduce the >>>> error by building the tests inside of otp/lib/CosNotification/test using >>>> make tests. >>>> >>>> Can anyone help? >>>> >>>> The following is the error I get. I have verified that the idl files are >>>> present in the src directory. >>>> >>>> erlc +debug_info -pa >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosNotification/ebin -pa >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosNotification/src -pa >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosTime/ebin -pa >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosTime/include -pa >>>> /home/ESLbingen/bingen/tmp/otp/lib/orber/ebin -pa >>>> /home/ESLbingen/bingen/tmp/otp/lib/ic/ebin -pa >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosNotification/include >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosEvent/src >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosNotification/include -pa >>>> /home/ESLbingen/bingen/tmp/otp/lib/orber/include -pa >>>> /home/ESLbingen/bingen/tmp/otp/internal_tools/test_server/ebin -pa >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosNotification/ebin -pa >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosNotification/test/idl_output -pa >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosTime/ebin -pa >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosTime/include -pa >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosNotification/include -pa >>>> /home/ESLbingen/bingen/tmp/otp/lib/ic/ebin >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosTime/ebin >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosTime/include >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/orber/include >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosNotification/src >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosNotification/include >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosNotification >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosNotification/test/idl_output >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/test_server/include -oidl_output \ >>>> +'{cfgfile,"notify_test_server.cfg"}' >>>> notify_test_server.idl >>>> []: warning: unrecognised option: debug_info >>>> Erlang IDL compiler version 4.2.26 >>>> "c:/cygwin/home/ESLBIN~1/bingen/tmp/otp/lib/COSNOT~1/test/notify_test_server.idl": >>>> preprocessor error: >>>> c:/cygwin/home/ESLBIN~1/bingen/tmp/otp/lib/COSNOT~1/test/notify_test_server.idl:23: >>>> CosNotification.idl: No such file or directory >>>> "c:/cygwin/home/ESLBIN~1/bingen/tmp/otp/lib/COSNOT~1/test/notify_test_server.idl": >>>> preprocessor error: >>>> c:/cygwin/home/ESLBIN~1/bingen/tmp/otp/lib/COSNOT~1/test/notify_test_server.idl:24: >>>> CosNotifyComm.idl: No such file or directory >>>> "c:/cygwin/home/ESLBIN~1/bingen/tmp/otp/lib/COSNOT~1/test/notify_test_server.idl": >>>> 2 errors found >>>> >>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>>> >>> >>> >>> -- >>> Regards, >>> Alexander >>> >>> >> > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From kostis@REDACTED Wed May 4 01:01:50 2011 From: kostis@REDACTED (Kostis Sagonas) Date: Wed, 04 May 2011 02:01:50 +0300 Subject: [erlang-questions] Dialyzer questions In-Reply-To: References: Message-ID: <4DC0895E.5050409@cs.ntua.gr> Prashanth Mundkur wrote: > We've recently been getting the upcoming release of Disco to go through > the Dialyzer wringer, and it has been a very useful exercise. Thanks to > Kostis' helpful wielding of the cluebat at the SF Erlang Factory! > > We are trying to understand the following output (I hope the inline code > pasting below comes out readable): You already figured out some answers to your questions, but let me also reply to them for completeness and hopefully also for more explanations. > $ cat dial.erl > -module(dial). > -export([abort/2, extract/2, > diskspace/1, monitor_diskspace/2, refresh_tags/1, > monitor_launch/0]). > > % We have helper functions like this: > abort(Msg, Code) -> > error_logger:warning_report(Msg), > exit(Code). > % which give rise to the following dialyzer message: > % > % Function abort/2 only terminates with explicit exception > % How do we interpret this message? First of all note that you do not get this warning by default. You only get this warning because you explicitly enabled the -Werror_handling option. I quote from the manual: -Werror_handling *** Include warnings for functions that only return by means of an exception. You can suppress this warning by adding a spec of the form: -spec abort(some_type(), some_other_type()) -> no_return(). for this function, which will notify dialyzer that it is indeed your intention that this function will never return a value > % Even with a plt that includes stdlib, there is no warning for the > % following code: > -spec extract(binary(), nonempty_string()) -> 'ok'. > extract(Pack, Dir) -> > case zip:extract(Pack, [{cwd, Dir}]) of > {ok, Files} -> > Files; > {error, Reason} -> > exit({error, Reason}) > end. This happens because module 'zip' does not have -spec information about its functions. Without such information, dialyzer's analysis infers that zip:extract/2 will either return something of the form {ok, term()} or {error, term()}. Note that the only thing that dialyzer can infer given this information is that Files will be some term(). Your spec promises is that this term is 'ok'. In such cases, where dialyzer cannot find any reason not to trust you, it keeps its mouth shut about it. (Unless you use option -Woverspecs in this case.) Now, it's actually the case that I have a spec-ed version of zip.erl which has not made it into OTP yet and in that version I get the following warning in your code: Invalid type specification for function dial:extract/2. The success typing is (binary() | string(),binary() | string()) -> [binary() | string() | {binary() | string(),binary()}] I will see whether this version can be included as in OTP or not... > % Here, the spawn_link of monitor_diskspace in monitor_launch() gives: > % The created fun has no local return > % whereas the spawn_link of refresh_tags doesn't. If the spawn_link > % of monitor_diskspace() function is commented out, there is no > % warning. It's not clear how to interpret the warning or the > % inconsistency. > % > % Converting the nested list comprehension in monitor_diskspace into a > % list:map made the warning go away, at the expense of readability and > % perhaps even efficiency. You are right. There is some inconsistency in the behavior of the two cases. But note that the funs that are created have no return -- they both call functions that go into an infinite loop and actually they are explicitly spec-ed as no returning. So the warning you get is correct. Still, you would like the two cases to be consistent and ideally also not get this warning, if possible. (So that you do not have to resort to calls outside this module as e.g. using lists:map/2.) We spend some time with Stavros today looking into this and Stavros has come up with a way of making sure the treatment of these two cases is consistent and the one you want. When such specs are in place for functions that go into infinite loops, the warnings for uses of them in funs are suppressed. Stay tuned and Stavros' patch will soon find its place to an OTP version near you! Hope this explains all issues, Kostis > -type diskinfo() :: {non_neg_integer(), non_neg_integer()}. > -spec diskspace(nonempty_string()) -> {'ok', diskinfo()} | {'error', > term()}. > diskspace(Path) -> > case Path of > "a" -> {ok, {0,0}}; > _ -> {error, error} > end. > > -spec monitor_diskspace(nonempty_string(), > [{diskinfo(), nonempty_string()}]) -> > no_return(). > monitor_diskspace(Root, Vols) -> > Df = fun(VolName) -> > diskspace(filename:join([Root, VolName])) > end, > NewVols = [{Space, VolName} > || {VolName, {ok, Space}} > <- [{VolName, Df(VolName)} > || {_OldSpace, VolName} <- Vols]], > monitor_diskspace(Root, NewVols). > > -spec refresh_tags(nonempty_string()) -> > no_return(). > refresh_tags(Root) -> > {ok, _} = diskspace(Root), > refresh_tags(Root). > > monitor_launch() -> > spawn_link(fun() -> refresh_tags("abc") end), > spawn_link(fun() -> monitor_diskspace("root", [{{0,0}, "a"}]) end). > > $ dialyzer --get_warnings -Wunmatched_returns -Werror_handling dial.erl > Checking whether the PLT /home/mundkur/.dialyzer_plt is up-to-date... yes > Proceeding with analysis... > dial.erl:6: Function abort/2 only terminates with explicit exception > dial.erl:66: The created fun has no local return From pmundkur.erlang@REDACTED Wed May 4 04:43:04 2011 From: pmundkur.erlang@REDACTED (Prashanth Mundkur) Date: Tue, 3 May 2011 19:43:04 -0700 Subject: [erlang-questions] Dialyzer questions In-Reply-To: <4DC0895E.5050409@cs.ntua.gr> References: <4DC0895E.5050409@cs.ntua.gr> Message-ID: <20110504024304.GA17546@damage.nokiapaloalto.com> Kostis Sagonas wrote: > Prashanth Mundkur wrote: > > We've recently been getting the upcoming release of Disco to go through > > the Dialyzer wringer, and it has been a very useful exercise. Thanks to > > Kostis' helpful wielding of the cluebat at the SF Erlang Factory! > > > > We are trying to understand the following output (I hope the inline code > > pasting below comes out readable): > > You already figured out some answers to your questions, but let me also > reply to them for completeness and hopefully also for more explanations. > > > $ cat dial.erl > > -module(dial). > > -export([abort/2, extract/2, > > diskspace/1, monitor_diskspace/2, refresh_tags/1, > > monitor_launch/0]). > > > > % We have helper functions like this: > > abort(Msg, Code) -> > > error_logger:warning_report(Msg), > > exit(Code). > > % which give rise to the following dialyzer message: > > % > > % Function abort/2 only terminates with explicit exception > > % How do we interpret this message? > > First of all note that you do not get this warning by default. You only > get this warning because you explicitly enabled the -Werror_handling > option. I quote from the manual: > > -Werror_handling *** > Include warnings for functions > that only return by means of an exception. > > You can suppress this warning by adding a spec of the form: > > -spec abort(some_type(), some_other_type()) -> no_return(). > > for this function, which will notify dialyzer that it is indeed your > intention that this function will never return a value > > > > % Even with a plt that includes stdlib, there is no warning for the > > % following code: > > -spec extract(binary(), nonempty_string()) -> 'ok'. > > extract(Pack, Dir) -> > > case zip:extract(Pack, [{cwd, Dir}]) of > > {ok, Files} -> > > Files; > > {error, Reason} -> > > exit({error, Reason}) > > end. > > This happens because module 'zip' does not have -spec information about > its functions. Without such information, dialyzer's analysis infers > that zip:extract/2 will either return something of the form {ok, term()} > or {error, term()}. Note that the only thing that dialyzer can infer > given this information is that Files will be some term(). Your spec > promises is that this term is 'ok'. In such cases, where dialyzer > cannot find any reason not to trust you, it keeps its mouth shut about > it. (Unless you use option -Woverspecs in this case.) Thanks, this clarifies a lot. > > Now, it's actually the case that I have a spec-ed version of zip.erl > which has not made it into OTP yet and in that version I get the > following warning in your code: > > Invalid type specification for function dial:extract/2. > The success typing is (binary() | string(),binary() | string()) -> > [binary() | string() | {binary() | string(),binary()}] > > I will see whether this version can be included as in OTP or not... > > > > % Here, the spawn_link of monitor_diskspace in monitor_launch() gives: > > % The created fun has no local return > > % whereas the spawn_link of refresh_tags doesn't. If the spawn_link > > % of monitor_diskspace() function is commented out, there is no > > % warning. It's not clear how to interpret the warning or the > > % inconsistency. > > % > > % Converting the nested list comprehension in monitor_diskspace into a > > % list:map made the warning go away, at the expense of readability and > > % perhaps even efficiency. > > You are right. There is some inconsistency in the behavior of the two > cases. But note that the funs that are created have no return -- they > both call functions that go into an infinite loop and actually they are > explicitly spec-ed as no returning. So the warning you get is correct. > Still, you would like the two cases to be consistent and ideally also > not get this warning, if possible. (So that you do not have to resort to > calls outside this module as e.g. using lists:map/2.) > > We spend some time with Stavros today looking into this and Stavros has > come up with a way of making sure the treatment of these two cases is > consistent and the one you want. When such specs are in place for > functions that go into infinite loops, the warnings for uses of them in > funs are suppressed. > > Stay tuned and Stavros' patch will soon find its place to an OTP version > near you! Excellent! > Hope this explains all issues, Yes, this was very helpful, thanks! One issue I forgot to ask about was the following: $ cat /tmp/dial.erl -module(dial). -export([f/1]). -type t() :: 'a' | 'b'. -spec f(atom()) -> t(). f(x) -> g(); f(y) -> h(). -spec g() -> t(). g() -> a. -spec h() -> t(). h() -> b. $ dialyzer /tmp/dial.erl dial.erl:12: The specification for dial:g/0 states that the function might also return 'b' but the inferred return is 'a' dial.erl:15: The specification for dial:h/0 states that the function might also return 'a' but the inferred return is 'b' This seems like a common problem when we use helper functions and don't want to separately type the return values of each of the helpers. Both -Wunderspecs and -Woverspecs don't help here. Is there an idiomatic way of avoiding this warning, other than omitting the -specs for the helpers altogether? --prashanth From dan@REDACTED Wed May 4 05:18:36 2011 From: dan@REDACTED (Daniel Dormont) Date: Tue, 3 May 2011 23:18:36 -0400 Subject: [erlang-questions] Why does fun2ms produce this particular result? In-Reply-To: References: Message-ID: Thanks, let me summarize to see if this is correct: 1) In general (though not in the case of ETS/Mnesia), the MatchBody might contain actions to be performed before returning the final result. This is why it's a list. 2) Actions may be specified in the form of a tuple, the first element of which describes the action to be performed. Therefore, if you want to have your "action" be a value which is itself a tuple, you have to wrap it in another tuple. Is this right? If so, I guess I understand what the rules are, but I'm still not really clear on why, since it seems like dbg and ets are different enough that you'd never really use the same kind of MatchSpec for both, so there isn't much benefit in having the structure be compatible. dan On Mon, May 2, 2011 at 2:35 AM, Mazen Harake wrote: > Check out chapter 2 in my dbg tutorial, it describes matchspecs and how to > use them. You will also understand what it is that fun2ms actually > translates to. > > > http://www.erlang-factory.com/conference/testingtutorialworkshop2010/speakers/MazenHarake > > Dbg matchspecs aren't exactly like the mnesia ones, there is a small > difference but the concept is exactly the same. > > /M > > On 1 May 2011 21:06, Daniel Dormont wrote: > >> I'm trying to get the hang of match specs. Here's a pretty simple one but >> it has a feature I'm not getting. It's intended for use with Mnesia: >> >> 1> rd(person, {name, address, email, phone}). >> person >> 2> ets:fun2ms(fun(#person{name=Name, email=Email}) -> {Name, Email} >> end). >> [{#person{name = '$1',address = '_',email = '$2', >> phone = '_'}, >> [], >> [{{'$1','$2'}}]}] >> >> My first question was going to be why the whole thing is a single-element >> list, but I think I figured that out: it's because there could be multiple >> clauses of the match as a whole. The part I don't get is in the result: >> [{{'$1','$2'}}] >> >> 1) Why is it a list at all, since a particular head in the function can >> only have one result? >> 2) Why does the tuple have to be wrapped in another tuple? ie why isn't it >> just {'$1','$2'} >> >> For now I'm happy to just trust that fun2ms works, but I'd like to >> understand it a little better. >> >> thanks, >> Dan >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kostis@REDACTED Wed May 4 08:18:37 2011 From: kostis@REDACTED (Kostis Sagonas) Date: Wed, 04 May 2011 09:18:37 +0300 Subject: [erlang-questions] Dialyzer questions In-Reply-To: <20110504024304.GA17546@damage.nokiapaloalto.com> References: <4DC0895E.5050409@cs.ntua.gr> <20110504024304.GA17546@damage.nokiapaloalto.com> Message-ID: <4DC0EFBD.1070308@cs.ntua.gr> Prashanth Mundkur wrote: > Yes, this was very helpful, thanks! One issue I forgot to ask about was the > following: > > $ cat /tmp/dial.erl > -module(dial). > -export([f/1]). > > -type t() :: 'a' | 'b'. > -spec f(atom()) -> t(). > > f(x) -> > g(); > f(y) -> > h(). > > -spec g() -> t(). > g() -> a. > > -spec h() -> t(). > h() -> b. > > $ dialyzer /tmp/dial.erl > dial.erl:12: The specification for dial:g/0 states that the function > might also return 'b' but the inferred return is 'a' > dial.erl:15: The specification for dial:h/0 states that the function > might also return 'a' but the inferred return is 'b' > > This seems like a common problem when we use helper functions and > don't want to separately type the return values of each of the > helpers. Both -Wunderspecs and -Woverspecs don't help here. Is there > an idiomatic way of avoiding this warning, other than omitting the > -specs for the helpers altogether? The short answer is NO. In simple cases like yours, I cannot see why you would not spec them as follows: -type a() :: a. -type b() :: b. -type t() :: a() | b(). -spec f(atom()) -> t(). -spec g() -> a(). -spec h() -> b(). Seems to me that this is exactly what the | operator in types is about. Now, of course if the code is more complicated than your example and the return types for the two helpers are not disjoint, then I can see the problem. In such cases, if the functions are module local, I suggest that you simply don't spec them. Kostis From sir.sedrik@REDACTED Wed May 4 08:56:32 2011 From: sir.sedrik@REDACTED (Fredrik Andersson) Date: Wed, 4 May 2011 08:56:32 +0200 Subject: [erlang-questions] Errors when generating tests for CosNotifications on windows. In-Reply-To: References: Message-ID: The path is not longer than 256 chars. I am using the one built and installed from source to generate the tests. I downloaded the latest version of cygwin when I started on this so it is not older than a couple of weeks. The installer is reporting 2.738 back to me. I currently have a new run going from a directory that has no seperate path longer than 8 chars to avoid the truncating in paths. Will let you know how it goes. On Wed, May 4, 2011 at 12:35 AM, OvermindDL1 wrote: > On May 3, 2011 7:36 AM, "Niclas Eklund" wrote: > > > > > > Hello! > > > > As you've probably guessed we don't encounter this problem. ;-) But then > the test suites are only built once (not a Windows machine) and then re-used > by different plattforms. Speed things up. > > > > Since there is a 256 chars limit (Windows paths and command line), this > might be it. I suppose that a faulty setting of one of the Erlang related > environment variables (e.g. ERL_TOP) could cause problems as well. Perhaps > you can e-mail them to me? > > As I recall Windows has a limit if 4096 per complete path if using the NT > api for note. 512 if 8.3 format is enabled in the registry. > > > > > Due to the fact that CosNotification depends on several other > Cos-services, more IDL files needs to be included compared with, for > example, CosTime. > > > > Best Regards, > > > > Niclas @ Erlang/OTP > > > > > > On Thu, 21 Apr 2011, Fredrik Andersson wrote: > > > >> On Thu, Apr 21, 2011 at 11:04 AM, Alexander Krasnukhin < > >> the.malkolm@REDACTED> wrote: > >> > >>> Hi, > >>> > >>> It is just a guess and probably sounds stupid but could you try to > compile > >>> within the folder with smaller path length? > >>> > >> > >> I tried moving the otp folder to / and it had no difference, I can make > them > >> all compile if I cp the idl files to the test folder of cosNotification > but > >> that seems to be a suboptimal way of doing things. > >> > >> > >>> > >>> On Thu, Apr 21, 2011 at 10:57 AM, Fredrik Andersson < > sir.sedrik@REDACTED>wrote: > >>> > >>>> Hi all > >>>> > >>>> I want to run the test suites on my windows build but I am running > into > >>>> trouble when generating the tests for CosNotification. I can reproduce > the > >>>> error by building the tests inside of otp/lib/CosNotification/test > using > >>>> make tests. > >>>> > >>>> Can anyone help? > >>>> > >>>> The following is the error I get. I have verified that the idl files > are > >>>> present in the src directory. > >>>> > >>>> erlc +debug_info -pa > >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosNotification/ebin -pa > >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosNotification/src -pa > >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosTime/ebin -pa > >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosTime/include -pa > >>>> /home/ESLbingen/bingen/tmp/otp/lib/orber/ebin -pa > >>>> /home/ESLbingen/bingen/tmp/otp/lib/ic/ebin -pa > >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosNotification/include > >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosEvent/src > >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosNotification/include -pa > >>>> /home/ESLbingen/bingen/tmp/otp/lib/orber/include -pa > >>>> /home/ESLbingen/bingen/tmp/otp/internal_tools/test_server/ebin -pa > >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosNotification/ebin -pa > >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosNotification/test/idl_output -pa > >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosTime/ebin -pa > >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosTime/include -pa > >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosNotification/include -pa > >>>> /home/ESLbingen/bingen/tmp/otp/lib/ic/ebin > >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosTime/ebin > >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosTime/include > >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/orber/include > >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosNotification/src > >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosNotification/include > >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosNotification > >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosNotification/test/idl_output > >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/test_server/include -oidl_output > \ > >>>> +'{cfgfile,"notify_test_server.cfg"}' > >>>> notify_test_server.idl > >>>> []: warning: unrecognised option: debug_info > >>>> Erlang IDL compiler version 4.2.26 > >>>> > "c:/cygwin/home/ESLBIN~1/bingen/tmp/otp/lib/COSNOT~1/test/notify_test_server.idl": > >>>> preprocessor error: > >>>> > c:/cygwin/home/ESLBIN~1/bingen/tmp/otp/lib/COSNOT~1/test/notify_test_server.idl:23: > >>>> CosNotification.idl: No such file or directory > >>>> > "c:/cygwin/home/ESLBIN~1/bingen/tmp/otp/lib/COSNOT~1/test/notify_test_server.idl": > >>>> preprocessor error: > >>>> > c:/cygwin/home/ESLBIN~1/bingen/tmp/otp/lib/COSNOT~1/test/notify_test_server.idl:24: > >>>> CosNotifyComm.idl: No such file or directory > >>>> > "c:/cygwin/home/ESLBIN~1/bingen/tmp/otp/lib/COSNOT~1/test/notify_test_server.idl": > >>>> 2 errors found > >>>> > >>>> > >>>> _______________________________________________ > >>>> erlang-questions mailing list > >>>> erlang-questions@REDACTED > >>>> http://erlang.org/mailman/listinfo/erlang-questions > >>>> > >>>> > >>> > >>> > >>> -- > >>> Regards, > >>> Alexander > >>> > >>> > >> > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mazen.harake@REDACTED Wed May 4 09:03:44 2011 From: mazen.harake@REDACTED (Mazen Harake) Date: Wed, 4 May 2011 09:03:44 +0200 Subject: [erlang-questions] Why does fun2ms produce this particular result? In-Reply-To: References: Message-ID: Well, yes. 1) Quoting documentation: "ETS match specifications are there to produce a return value. Usually the MatchBody contains one single ConditionExpression which defines the return value without having any side effects. Calls with side effects are not allowed in the ETS context. When tracing there is no return value to produce, the match specification either matches or doesn't. The effect when the expression matches is a trace message rather then a returned term. The ActionTerm's are executed as in an imperative language, i.e. for their side effects. Functions with side effects are also allowed when tracing. In ETS the match head is a tuple() (or a single match variable) while it is a list (or a single match variable) when tracing." So in other words (in the context of dbg): yes, it is a list because you can have several "actions" in it. But in the context of ets there is usually only 1 namely what you want to return, if you have more than 1 then the last one will be returned. 2) This is correct. I would say the opposite; I see it as semantics of both are similar enough to use a "mini language" with exceptions rather than 2 different specifications all together, but I guess that is just a matter of personal taste. /M On 4 May 2011 05:18, Daniel Dormont wrote: > Thanks, let me summarize to see if this is correct: > > 1) In general (though not in the case of ETS/Mnesia), the MatchBody might > contain actions to be performed before returning the final result. This is > why it's a list. > 2) Actions may be specified in the form of a tuple, the first element of > which describes the action to be performed. Therefore, if you want to have > your "action" be a value which is itself a tuple, you have to wrap it in > another tuple. > > Is this right? If so, I guess I understand what the rules are, but I'm > still not really clear on why, since it seems like dbg and ets are different > enough that you'd never really use the same kind of MatchSpec for both, so > there isn't much benefit in having the structure be compatible. > > dan > > On Mon, May 2, 2011 at 2:35 AM, Mazen Harake wrote: > >> Check out chapter 2 in my dbg tutorial, it describes matchspecs and how to >> use them. You will also understand what it is that fun2ms actually >> translates to. >> >> >> http://www.erlang-factory.com/conference/testingtutorialworkshop2010/speakers/MazenHarake >> >> Dbg matchspecs aren't exactly like the mnesia ones, there is a small >> difference but the concept is exactly the same. >> >> /M >> >> On 1 May 2011 21:06, Daniel Dormont wrote: >> >>> I'm trying to get the hang of match specs. Here's a pretty simple one but >>> it has a feature I'm not getting. It's intended for use with Mnesia: >>> >>> 1> rd(person, {name, address, email, phone}). >>> person >>> 2> ets:fun2ms(fun(#person{name=Name, email=Email}) -> {Name, Email} >>> end). >>> [{#person{name = '$1',address = '_',email = '$2', >>> phone = '_'}, >>> [], >>> [{{'$1','$2'}}]}] >>> >>> My first question was going to be why the whole thing is a single-element >>> list, but I think I figured that out: it's because there could be multiple >>> clauses of the match as a whole. The part I don't get is in the result: >>> [{{'$1','$2'}}] >>> >>> 1) Why is it a list at all, since a particular head in the function can >>> only have one result? >>> 2) Why does the tuple have to be wrapped in another tuple? ie why isn't >>> it just {'$1','$2'} >>> >>> For now I'm happy to just trust that fun2ms works, but I'd like to >>> understand it a little better. >>> >>> thanks, >>> Dan >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimo+erlang-questions@REDACTED Wed May 4 09:57:34 2011 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Wed, 4 May 2011 09:57:34 +0200 Subject: [erlang-questions] byte() vs. char() use in documentation In-Reply-To: <201105040533.58985.als@iinet.net.au> References: <20110502091415.GA6512@erix.ericsson.se> <20110503094549.GA10981@erix.ericsson.se> <201105040533.58985.als@iinet.net.au> Message-ID: <20110504075734.GA16456@erix.ericsson.se> On Wed, May 04, 2011 at 05:33:58AM +1000, Anthony Shipman wrote: > On Tue, 3 May 2011 07:45:49 pm Raimo Niskanen wrote: > > The programmer should regard strings as a sequence of unicode code points. > > As such they are just that and there is no encoding to bother about. > > The code point number uniquely defines which unicode character it is. > > As I recall, a Unicode character can be composed of up to 7 code points. > To quote a text book I'm looking at now: > ------------- > The trick is, again, to disabuse yourself of the idea that a one-to-one > correspondence exists between "characters" as the user is used to thinking of > them and code points (or code units) in the backing store. Unicode uses the > term "character" to mean more or less "the entity that's represented by a > single Unicode code point," but this concept doesn't always match the user's > definition of "character". > ------------- There seems to be a terminology here clash that I will remember for the future. When I talked about "Unicode code points" I ment the character number in the Unicode system. I did not think it was allowed to talk about "code points" when talking about byte encoded data. There are text books that talk about "code points (or code units) in the backing store". I find that very confusing. I will aways call it "byte encoding" or something like that. > > I think a more complete design would represent a character as a binary that is > a UTF8 encoding of its code points. A string would then be a deep list of > these binaries. > > -- > Anthony Shipman Mamas don't let your babies > als@REDACTED grow up to be outsourced. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From raimo+erlang-questions@REDACTED Wed May 4 10:11:42 2011 From: raimo+erlang-questions@REDACTED ('Raimo Niskanen') Date: Wed, 4 May 2011 10:11:42 +0200 Subject: [erlang-questions] byte() vs. char() use in documentation In-Reply-To: <001801cc09cd$72129d70$5637d850$@com> References: <20110502091415.GA6512@erix.ericsson.se> <372726991.139721304328918708.JavaMail.root@zimbra> <20110502095824.GA9576@erix.ericsson.se> <4DBE83B4.50501@cs.ntua.gr> <20110503094549.GA10981@erix.ericsson.se> <001801cc09cd$72129d70$5637d850$@com> Message-ID: <20110504081142.GB16456@erix.ericsson.se> On Tue, May 03, 2011 at 03:05:24PM -0500, David Mercer wrote: > On Tuesday, May 03, 2011, Raimo Niskanen wrote: > > > I repeat again. The programmer decides what the bytes mean. The list > > [0,0,16#21,16#2b] e.g would mean "angstrom sign" if the encoding is > > UTF-32 big endian. And that is a valid iolist. > > But [16#212b] is not. > > Out of curiosity, why does > > unicode:characters_to_binary([16#212b], {utf32, big}). Man page says: characters_to_binary(Data,InEncoding) -> binary() | ... You changed the InEncoding to {utf32,big}. You want this: characters_to_binary(Data, InEncoding, OutEncoding) -> binary() | ... 1> unicode:characters_to_binary([16#212b], unicode, {utf32, big}). <<0,0,33,43>> > > return the UTF-8 representation of ?$B"r (Angstrom sign) and not the big-endian > UTF-32 like I expected? InEncoding only applies to binaries in the indata since integers are just Unicode code points and have no encoding: 2> unicode:characters_to_binary([16#212b,<<226,132,171>>], utf8, {utf32, big}). <<0,0,33,43,0,0,33,43>> Note: unicode is an alias for utf8 in the unicode module since utf8 is the default encoding It is all in the Erlang man page for unicode(3). -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From ingela@REDACTED Wed May 4 10:29:26 2011 From: ingela@REDACTED (Ingela Andin) Date: Wed, 4 May 2011 10:29:26 +0200 Subject: [erlang-questions] Erlang and MySQL: ODBC, Column type not supported In-Reply-To: References: <4DBE7B49.1080505@erix.ericsson.se> Message-ID: Hi! It looks like a good start :-) Your patch does not address parameterized queries, it would be nice if it did, even if it is interesting even without that support. You also need to contribute test cases and updated documentation. Please follow the instructions from: https://github.com/erlang/otp/wiki/submitting-patches Regards Ingela Erlang-OTP team - Ericsson AB 2011/5/3 Hanfei Shen : > Hi, > > It does solve THIS problem, but not all... :( > > Briefly, it does not support the mysql column type TEXT (the unicode one). > So I made a patch to solve the unicode TEXT problem. > > Thanks to Juhani R?nkimies, most of hard work has been done by him, I just > add some lines to the file odbcserver.c and it works well for me. > > Here is my git repository: > git://github.com/qqshfox/otp.git > > and branch: > odbc_sql_wlongvarchar_support > > This is the first time I submit a patch to a open source project, I'd > greatly appreciate if you could kindly review my code. :) > > > 2011/5/3 Ingela Andin >> >> Hi! >> >> Ok problem solved then, from the releasenotes of ?odbc version 2.10.8: >> >> "1.3 ?ODBC 2.10.8 >> Improvements and New Features >> >> ? ?* >> >> ? ? ?ODBC now handles the types SQL_WCHAR and SQL_WVARCHAR. Thanks to >> Juhani R?nkimies. ODBC also has a new connection option to return all >> strings as binaries and also expect strings to be binaries in the >> param_query function. These changes provides some unicode support. >> >> ? ? ?Own Id: OTP-7452" >> >> >> You had version 2.10.7 ?and latest version (in R14B02) is 2.10.10. >> >> Regards Ingela Erlang/OTP team - Ericsson AB >> >> >> 2011/5/3 Hanfei Shen : >> > Hi, >> > >> > It returns: >> > >> > {ok,[{"id",sql_integer}, >> > ???? {"code",{sql_wvarchar,255}}, >> > ???? {"compliment_desc",{sql_wvarchar,255}}, >> > ???? {"status_desc",{sql_wvarchar,255}}, >> > ???? {"parameter",{sql_wvarchar,255}}, >> > ???? {"cause",{sql_wvarchar,255}}, >> > ???? {"disabled",sql_tinyint}]} >> > >> > I found that the macro SQL_WVARCHAR is defined in sqlucode.h. >> > >> > 2011/5/3 Ingela Andin >> >> >> >> Hi! >> >> >> >> Interesting what does odbc:describe_table/2 return on >> >> R14B02 ? >> >> >> >> Regards Ingela Erlang/OTP team - Ericsson AB >> >> >> >> >> >> 2011/5/3 Hanfei Shen : >> >> > Hi, >> >> > >> >> > Well it works on R14B02... >> >> > >> >> > 2011/5/3 Hanfei Shen >> >> >> >> >> >> Hi, >> >> >> >> >> >> The same on my windows 7 32 bit workstation. >> >> >> >> >> >> Erlang R13B02 (erts-5.7.3) >> >> >> >> >> >> 4> code:which(odbc). >> >> >> "d:/PROGRA~1/ERL57~1.3/lib/odbc-2.10.5/ebin/odbc.beam" >> >> >> >> >> >> mysql odbc 5.1.8 >> >> >> >> >> >> >> >> >> >> >> >> I'm downloading the latest version of erlang (R14B02)... >> >> >> >> >> >> >> >> >> 2011/5/3 Hanfei Shen >> >> >>> >> >> >>> Hi, >> >> >>> >> >> >>> I had set up a fresh system and reproduce this problem >> >> >>> successfully. >> >> >>> Here is something about my installations: >> >> >>> >> >> >>> vm: >> >> >>> VirtualBox 4.0.6 r71416 >> >> >>> >> >> >>> gentoo: >> >> >>> livecd: install-amd64-minimal-20110317.iso >> >> >>> stage: stage3-amd64-20110428.tar.bz2 >> >> >>> portage: portage-20110424.tar.bz2 >> >> >>> >> >> >>> I only installed: >> >> >>> >> >> >>> dev-db/mysql-5.1.51 >> >> >>> dev-db/myodbc-5.1.6 >> >> >>> dev-lang/erlang-13.2.4 USE="kpoll odbc smp" >> >> >>> >> >> >>> table schema: >> >> >>> >> >> >>> CREATE TABLE `action` ( >> >> >>> ? `id` int(11) NOT NULL AUTO_INCREMENT, >> >> >>> ? `code` varchar(255) NOT NULL, >> >> >>> ? `compliment_desc` varchar(255) NOT NULL DEFAULT '', >> >> >>> ? `status_desc` varchar(255) NOT NULL DEFAULT '', >> >> >>> ? `parameter` varchar(255) NOT NULL DEFAULT '', >> >> >>> ? `cause` varchar(255) NOT NULL DEFAULT '', >> >> >>> ? `disabled` tinyint(1) NOT NULL DEFAULT '0', >> >> >>> ? PRIMARY KEY (`id`), >> >> >>> ? UNIQUE KEY `index_action_on_cause` (`cause`) >> >> >>> ) ENGINE=InnoDB AUTO_INCREMENT=56 DEFAULT CHARSET=utf8; >> >> >>> >> >> >>> >> >> >>>> I see you are running on a 64 bit ?platform, maybe you can try ?it >> >> >>>> also >> >> >>>> on a 32 bit platform. ?Maybe >> >> >>>> you could try accessing the database from windows using the >> >> >>>> windows >> >> >>>> my-sql driver. >> >> >>> >> >> >>> I reproduced the problem on a 32bit server just right now... >> >> >>> >> >> >>> I'll try it on a windows machine asap. >> >> >>> >> >> >>> 2011/5/3 Hanfei Shen : >> >> >>> > Hi, >> >> >>> > >> >> >>> > Hmmmmmm... The unixODBC is already in my system, but I don't know >> >> >>> > how >> >> >>> > to use it... >> >> >>> > >> >> >>> > I will setup a vm with fresh system tomorrow to reproduce the >> >> >>> > problem... >> >> >>> > >> >> >>> > PS, could you figure out a name of ANOTHER ODBC-DRIVER which you >> >> >>> > mentioned? >> >> >>> > >> >> >>> > 2011/5/3 Hanfei Shen : >> >> >>> >> Hi, >> >> >>> >> >> >> >>> >> I've tried https://github.com/dizzyd/erlang-mysql-driver, it >> >> >>> >> works. >> >> >>> >> >> >> >>> >> I'm installing unixodbc... Wait a minute. Thnx... >> >> >>> >> >> >> >>> >> >> >> >>> >> 2011/5/3 Ingela Andin : >> >> >>> >>> Hi! >> >> >>> >>> >> >> >>> >>> Well the best thing would be if you can provide me with a way >> >> >>> >>> to >> >> >>> >>> reproduce it. >> >> >>> >>> Do you have the possibility to try another odbc-driver with >> >> >>> >>> your >> >> >>> >>> database? >> >> >>> >>> >> >> >>> >>> Regards Ingela Erlang/OTP team - Ericsson AB >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> 2011/5/2 Hanfei Shen : >> >> >>> >>>> Hi, >> >> >>> >>>> >> >> >>> >>>> I had changed the type from SQLINTEGER to SQLSMALLINT, but the >> >> >>> >>>> problem >> >> >>> >>>> is still there... >> >> >>> >>>> >> >> >>> >>>> (gdb) i func encode_data_type >> >> >>> >>>> File odbcserver.c: >> >> >>> >>>> static void encode_data_type(SQLSMALLINT, SQLINTEGER, >> >> >>> >>>> SQLSMALLINT, >> >> >>> >>>> db_state *); >> >> >>> >>>> >> >> >>> >>>> Breakpoint 1, encode_data_type (sql_type=-9, size=255, >> >> >>> >>>> decimal_digits=0, state=0x7fffa5380210) at odbcserver.c:1396 >> >> >>> >>>> 1396 ? ? ? ?switch(sql_type) { >> >> >>> >>>> >> >> >>> >>>> Do you need any details? >> >> >>> >>>> >> >> >>> >>>> 2011/5/2 Ingela Anderton Andin : >> >> >>> >>>>> Hi! >> >> >>> >>>>> >> >> >>> >>>>> Hanfei Shen wrote: >> >> >>> >>>>>> >> >> >>> >>>>>> Hi Ingela, >> >> >>> >>>>>> >> >> >>> >>>>>> Did you mean the value of variable "sql_type"? >> >> >>> >>>>>> >> >> >>> >>>>>> >> >> >>> >>>>> >> >> >>> >>>>> Yes. >> >> >>> >>>>> >> >> >>> >>>>>> I tried to inspect it through gdb, setting a break on func >> >> >>> >>>>>> encode_data_type. And then I got: >> >> >>> >>>>>> >> >> >>> >>>>>> Breakpoint 1, encode_data_type (sql_type=-9, size=255, >> >> >>> >>>>>> decimal_digits=0, state=0x7fffc657ec40) at odbcserver.c:1396 >> >> >>> >>>>>> 1396 ? ? ? ?switch(sql_type) { >> >> >>> >>>>>> >> >> >>> >>>>>> >> >> >>> >>>>> >> >> >>> >>>>> Well that is defenetly not a good value. Looking at the code >> >> >>> >>>>> just >> >> >>> >>>>> now >> >> >>> >>>>> I noticed that >> >> >>> >>>>> >> >> >>> >>>>> encode_data_type defines sql_type as "SQLINTEGER sql_type" >> >> >>> >>>>> and >> >> >>> >>>>> it >> >> >>> >>>>> ought to be "SQLSMALLINT sql_type". If you change that does >> >> >>> >>>>> it >> >> >>> >>>>> fix >> >> >>> >>>>> your >> >> >>> >>>>> problem? >> >> >>> >>>>> >> >> >>> >>>>> Regards Ingela Erlang/OTP team - Ericsson AB >> >> >>> >>>>> >> >> >>> >>>>> >> >> >>> >>>>> >> >> >>> >>>>>> 2011/5/2 Ingela Andin : >> >> >>> >>>>>> >> >> >>> >>>>>>> >> >> >>> >>>>>>> Hi! >> >> >>> >>>>>>> >> >> >>> >>>>>>> The erlang odbc application supports {sql-varchars, ?N} >> >> >>> >>>>>>> where >> >> >>> >>>>>>> N = >> >> >>> >>>>>>> 255 >> >> >>> >>>>>>> in your case. The return values >> >> >>> >>>>>>> you get suggest that the odbc-driver you have returns an >> >> >>> >>>>>>> unexpected >> >> >>> >>>>>>> column type. >> >> >>> >>>>>>> >> >> >>> >>>>>>> In the erlang odbc port program there is a switch that >> >> >>> >>>>>>> handles >> >> >>> >>>>>>> type >> >> >>> >>>>>>> when describing a coloumn that if we take out >> >> >>> >>>>>>> the handling code looks like this. >> >> >>> >>>>>>> >> >> >>> >>>>>>> switch(sql_type) { >> >> >>> >>>>>>> ? case SQL_CHAR: >> >> >>> >>>>>>> ? case SQL_VARCHAR: >> >> >>> >>>>>>> ? case SQL_WCHAR: >> >> >>> >>>>>>> ? case SQL_WVARCHAR: >> >> >>> >>>>>>> ? case SQL_NUMERIC: >> >> >>> >>>>>>> ? case SQL_DECIMAL: >> >> >>> >>>>>>> ? case SQL_INTEGER: >> >> >>> >>>>>>> ? case SQL_TINYINT: >> >> >>> >>>>>>> ? case SQL_SMALLINT: >> >> >>> >>>>>>> ? case SQL_REAL: >> >> >>> >>>>>>> ? case SQL_FLOAT: >> >> >>> >>>>>>> ? case SQL_DOUBLE: >> >> >>> >>>>>>> ? case SQL_BIT: >> >> >>> >>>>>>> ? case SQL_TYPE_DATE: >> >> >>> >>>>>>> ? case SQL_TYPE_TIME: >> >> >>> >>>>>>> ? case SQL_TYPE_TIMESTAMP: >> >> >>> >>>>>>> ? case SQL_BIGINT: >> >> >>> >>>>>>> ? case SQL_BINARY: >> >> >>> >>>>>>> ? case SQL_LONGVARCHAR: >> >> >>> >>>>>>> ? case SQL_VARBINARY: >> >> >>> >>>>>>> ? case SQL_LONGVARBINARY: >> >> >>> >>>>>>> ? case SQL_INTERVAL_MONTH: >> >> >>> >>>>>>> ? case SQL_INTERVAL_YEAR: >> >> >>> >>>>>>> ? case SQL_INTERVAL_DAY: >> >> >>> >>>>>>> ? case SQL_INTERVAL_MINUTE: >> >> >>> >>>>>>> ? case SQL_INTERVAL_HOUR_TO_SECOND: >> >> >>> >>>>>>> ? case SQL_INTERVAL_MINUTE_TO_SECOND: >> >> >>> >>>>>>> ? case SQL_UNKNOWN_TYPE: >> >> >>> >>>>>>> ? default: /* Will probably never happen */ >> >> >>> >>>>>>> ? ? ? ei_x_encode_atom(&dynamic_buffer(state), >> >> >>> >>>>>>> "ODBC_UNSUPPORTED_TYPE"); >> >> >>> >>>>>>> ? ? ? break; >> >> >>> >>>>>>> ? } >> >> >>> >>>>>>> >> >> >>> >>>>>>> >> >> >>> >>>>>>> And you end up in the default clause which is very >> >> >>> >>>>>>> unexpected >> >> >>> >>>>>>> and >> >> >>> >>>>>>> the >> >> >>> >>>>>>> root to your problem. ?If ?you can figur out >> >> >>> >>>>>>> what your driver returns for the ODBC C-API function >> >> >>> >>>>>>> SQLDescribeCol we >> >> >>> >>>>>>> could know if the driver is at fault or if the odbc-port >> >> >>> >>>>>>> program >> >> >>> >>>>>>> is. >> >> >>> >>>>>>> >> >> >>> >>>>>>> Regards ?Ingela Erlang/OTP team - Ericsson AB >> >> >>> >>>>>>> >> >> >>> >>>>>>> 2011/5/1 Hanfei Shen : >> >> >>> >>>>>>> >> >> >>> >>>>>>>> >> >> >>> >>>>>>>> Dear all, >> >> >>> >>>>>>>> >> >> >>> >>>>>>>> I'm a newbie programming in erlang. When I used ODBC to >> >> >>> >>>>>>>> connect >> >> >>> >>>>>>>> to a >> >> >>> >>>>>>>> MySQL database through Connector/ODBC (MyODBC), I got some >> >> >>> >>>>>>>> error >> >> >>> >>>>>>>> when >> >> >>> >>>>>>>> calling odbc:sql_query(Conn, "SELECT * FROM action"): >> >> >>> >>>>>>>> >> >> >>> >>>>>>>> {error,"Column type not supported"} >> >> >>> >>>>>>>> >> >> >>> >>>>>>>> Then I call odbc:describe_table(Conn, "action"), it >> >> >>> >>>>>>>> returned: >> >> >>> >>>>>>>> >> >> >>> >>>>>>>> {ok,[{"id",sql_integer}, >> >> >>> >>>>>>>> ? ? {"code",'ODBC_UNSUPPORTED_TYPE'}, >> >> >>> >>>>>>>> ? ? {"compliment_desc",'ODBC_UNSUPPORTED_TYPE'}, >> >> >>> >>>>>>>> ? ? {"status_desc",'ODBC_UNSUPPORTED_TYPE'}, >> >> >>> >>>>>>>> ? ? {"parameter",'ODBC_UNSUPPORTED_TYPE'}, >> >> >>> >>>>>>>> ? ? {"cause",'ODBC_UNSUPPORTED_TYPE'}, >> >> >>> >>>>>>>> ? ? {"disabled",sql_tinyint}]} >> >> >>> >>>>>>>> >> >> >>> >>>>>>>> And desc the table in mysql client: >> >> >>> >>>>>>>> mysql> desc action; >> >> >>> >>>>>>>> >> >> >>> >>>>>>>> >> >> >>> >>>>>>>> >> >> >>> >>>>>>>> >> >> >>> >>>>>>>> +-----------------+--------------+------+-----+---------+----------------+ >> >> >>> >>>>>>>> | Field ? ? ? ? ? | Type ? ? ? ? | Null | Key | Default | >> >> >>> >>>>>>>> Extra >> >> >>> >>>>>>>> ?| >> >> >>> >>>>>>>> >> >> >>> >>>>>>>> >> >> >>> >>>>>>>> >> >> >>> >>>>>>>> >> >> >>> >>>>>>>> +-----------------+--------------+------+-----+---------+----------------+ >> >> >>> >>>>>>>> | id ? ? ? ? ? ? ?| int(11) ? ? ?| NO ? | PRI | NULL ? ?| >> >> >>> >>>>>>>> auto_increment >> >> >>> >>>>>>>> | >> >> >>> >>>>>>>> | code ? ? ? ? ? ?| varchar(255) | NO ? | ? ? | NULL ? ?| >> >> >>> >>>>>>>> ?| >> >> >>> >>>>>>>> | compliment_desc | varchar(255) | NO ? | ? ? | ? ? ? ? | >> >> >>> >>>>>>>> ?| >> >> >>> >>>>>>>> | status_desc ? ? | varchar(255) | NO ? | ? ? | ? ? ? ? | >> >> >>> >>>>>>>> ?| >> >> >>> >>>>>>>> | parameter ? ? ? | varchar(255) | NO ? | ? ? | ? ? ? ? | >> >> >>> >>>>>>>> ?| >> >> >>> >>>>>>>> | cause ? ? ? ? ? | varchar(255) | NO ? | UNI | ? ? ? ? | >> >> >>> >>>>>>>> ?| >> >> >>> >>>>>>>> | disabled ? ? ? ?| tinyint(1) ? | NO ? | ? ? | 0 ? ? ? | >> >> >>> >>>>>>>> ?| >> >> >>> >>>>>>>> >> >> >>> >>>>>>>> >> >> >>> >>>>>>>> >> >> >>> >>>>>>>> >> >> >>> >>>>>>>> +-----------------+--------------+------+-----+---------+----------------+ >> >> >>> >>>>>>>> >> >> >>> >>>>>>>> It seems that Erlang ODBC driver does not support the >> >> >>> >>>>>>>> mysql >> >> >>> >>>>>>>> type >> >> >>> >>>>>>>> varchar? How can I use the database without touching the >> >> >>> >>>>>>>> db >> >> >>> >>>>>>>> schema? >> >> >>> >>>>>>>> >> >> >>> >>>>>>>> >> >> >>> >>>>>>>> Some details about the system env: >> >> >>> >>>>>>>> >> >> >>> >>>>>>>> $ uname -a >> >> >>> >>>>>>>> Linux 2.6.36-gentoo-r8 #4 SMP Thu Apr 7 20:13:18 CST 2011 >> >> >>> >>>>>>>> x86_64 >> >> >>> >>>>>>>> Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz GenuineIntel >> >> >>> >>>>>>>> GNU/Linux >> >> >>> >>>>>>>> >> >> >>> >>>>>>>> $ erl >> >> >>> >>>>>>>> Erlang R13B04 (erts-5.7.5) [source] [64-bit] [smp:2:2] >> >> >>> >>>>>>>> [rq:2] >> >> >>> >>>>>>>> [async-threads:0] [kernel-poll:false] >> >> >>> >>>>>>>> >> >> >>> >>>>>>>> $ emerge -vp erlang >> >> >>> >>>>>>>> dev-lang/erlang-13.2.4 ?USE="doc kpoll odbc smp ssl -emacs >> >> >>> >>>>>>>> -hipe >> >> >>> >>>>>>>> -java >> >> >>> >>>>>>>> -sctp -tk -wxwidgets" >> >> >>> >>>>>>>> >> >> >>> >>>>>>>> eshell> code:which(odbc). >> >> >>> >>>>>>>> "/usr/lib64/erlang/lib/odbc-2.10.7/ebin/odbc.beam" >> >> >>> >>>>>>>> >> >> >>> >>>>>>>> $ mysql -V >> >> >>> >>>>>>>> mysql ?Ver 14.14 Distrib 5.1.51, for pc-linux-gnu (x86_64) >> >> >>> >>>>>>>> using >> >> >>> >>>>>>>> readline 5.1 >> >> >>> >>>>>>>> >> >> >>> >>>>>>>> Server version: 5.1.51-log Gentoo Linux mysql-5.1.51 >> >> >>> >>>>>>>> >> >> >>> >>>>>>>> $ emerge -vp myodbc >> >> >>> >>>>>>>> dev-db/myodbc-5.1.6 ?USE="-debug -doc -qt4 -static" >> >> >>> >>>>>>>> >> >> >>> >>>>>>>> >> >> >>> >>>>>>>> Any help will be greatly appreciated. ?Thanks in advance. >> >> >>> >>>>>>>> Sorry for my poor English, I'm not a native... >> >> >>> >>>>>>>> >> >> >>> >>>>>>>> Best, >> >> >>> >>>>>>>> >> >> >>> >>>>>>>> -- >> >> >>> >>>>>>>> Hanfei >> >> >>> >>>>>>>> _______________________________________________ >> >> >>> >>>>>>>> erlang-questions mailing list >> >> >>> >>>>>>>> erlang-questions@REDACTED >> >> >>> >>>>>>>> http://erlang.org/mailman/listinfo/erlang-questions >> >> >>> >>>>>>>> >> >> >>> >>>>>>>> >> >> >>> >>>>>> >> >> >>> >>>>>> >> >> >>> >>>>> >> >> >>> >>>>> >> >> >>> >>>> _______________________________________________ >> >> >>> >>>> erlang-questions mailing list >> >> >>> >>>> erlang-questions@REDACTED >> >> >>> >>>> http://erlang.org/mailman/listinfo/erlang-questions >> >> >>> >>>> >> >> >>> >>> >> >> >>> >> >> >> >>> > >> >> >>> >> >> >> >> >> > >> >> > >> >> > _______________________________________________ >> >> > erlang-questions mailing list >> >> > erlang-questions@REDACTED >> >> > http://erlang.org/mailman/listinfo/erlang-questions >> >> > >> >> > >> > >> > > > From masklinn@REDACTED Wed May 4 10:40:41 2011 From: masklinn@REDACTED (Masklinn) Date: Wed, 4 May 2011 10:40:41 +0200 Subject: [erlang-questions] byte() vs. char() use in documentation In-Reply-To: <20110504075734.GA16456@erix.ericsson.se> References: <20110502091415.GA6512@erix.ericsson.se> <20110503094549.GA10981@erix.ericsson.se> <201105040533.58985.als@iinet.net.au> <20110504075734.GA16456@erix.ericsson.se> Message-ID: <3D99B655-CE55-4EE3-8C46-00C0DB2B5082@masklinn.net> On 2011-05-04, at 09:57 , Raimo Niskanen wrote: > On Wed, May 04, 2011 at 05:33:58AM +1000, Anthony Shipman wrote: >> On Tue, 3 May 2011 07:45:49 pm Raimo Niskanen wrote: >>> The programmer should regard strings as a sequence of unicode code points. >>> As such they are just that and there is no encoding to bother about. >>> The code point number uniquely defines which unicode character it is. >> >> As I recall, a Unicode character can be composed of up to 7 code points. >> To quote a text book I'm looking at now: >> ------------- >> The trick is, again, to disabuse yourself of the idea that a one-to-one >> correspondence exists between "characters" as the user is used to thinking of >> them and code points (or code units) in the backing store. Unicode uses the >> term "character" to mean more or less "the entity that's represented by a >> single Unicode code point," but this concept doesn't always match the user's >> definition of "character". >> ------------- > > There seems to be a terminology here clash that I will remember for the future. > When I talked about "Unicode code points" I ment the character number > in the Unicode system. I did not think it was allowed to talk about "code points" > when talking about byte encoded data. Well, code points are abstract numbers, but UTF-32 (as far as I know) encodes the code points as themselves. So many people make the shortcut (furthermore most people aren't really interested in understanding Unicode ? and I can understand that, it's a drag ? so they mix unicode-lingo with "normal" speech leading to less-than-sensical results). I believe the issue Anthony mentions here is the difference between glyphs and code points (combining marks) rather than the difference between code points and on-disk bytes (resulting from Unicode encoding): a "visible character" (e.g. ???) can be composed of multiple code points, one "base" code point and a number of combining marks code points (diacritics being the main offender) (nb: the glyph "???" is, in fact, composed of three code points: U+012F, U+0307 and U+0301). What most users think of as a character is what unicode calls a glyph: it's the graphical representation of a group of combined code points (that group may be unary). Whereas in Unicode, a character is the graphical representation of a single code point. As a result, a "user" character may be composed of a number of "unicode" characters. From mrtndimitrov@REDACTED Wed May 4 10:42:17 2011 From: mrtndimitrov@REDACTED (Martin Dimitrov) Date: Wed, 04 May 2011 11:42:17 +0300 Subject: [erlang-questions] child processes order of termination Message-ID: <4DC11169.3030507@gmail.com> Hi, On application stop what is the order of termination of the supervised processes? For example, the supervisor's children are defined as follows: {ok, {{one_for_all, 5, 1}, [ {module1, {module1, start_link, []}, permanent, 2000, worker, [module1]}, {module2, {module2, start_link, []}, permanent, infinity, supervisor, [module2]}, {module3, {module3, start_link, []}, permanent, 2000, worker, [module3]} ] }}. In what order they will be terminated? Is it determined? The module2 is also a supervisor, will its children be terminated before proceeding with the top one? Thanks, Martin From spawn.think@REDACTED Wed May 4 10:54:57 2011 From: spawn.think@REDACTED (Ahmed Omar) Date: Wed, 4 May 2011 10:54:57 +0200 Subject: [erlang-questions] child processes order of termination In-Reply-To: <4DC11169.3030507@gmail.com> References: <4DC11169.3030507@gmail.com> Message-ID: It's done in reversed start order. When Module2 is a supervisor, his children will be stopped first. http://www.erlang.org/doc/design_principles/sup_princ.html#id69917 On Wed, May 4, 2011 at 10:42 AM, Martin Dimitrov wrote: > Hi, > > On application stop what is the order of termination of the supervised > processes? > > For example, the supervisor's children are defined as follows: > > {ok, {{one_for_all, 5, 1}, > [ > {module1, {module1, start_link, []}, permanent, 2000, worker, > [module1]}, > {module2, {module2, start_link, []}, permanent, infinity, > supervisor, [module2]}, > {module3, {module3, start_link, []}, permanent, 2000, worker, > [module3]} > ] > }}. > > In what order they will be terminated? Is it determined? > > The module2 is also a supervisor, will its children be terminated before > proceeding with the top one? > > Thanks, > > Martin > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrtndimitrov@REDACTED Wed May 4 10:58:29 2011 From: mrtndimitrov@REDACTED (Martin Dimitrov) Date: Wed, 04 May 2011 11:58:29 +0300 Subject: [erlang-questions] child processes order of termination In-Reply-To: References: <4DC11169.3030507@gmail.com> Message-ID: <4DC11535.80902@gmail.com> Thanks a lot. So I did it again - ask before carefully read. Sorry. Best regards, Martin On 5/4/2011 11:54 AM, Ahmed Omar wrote: > It's done in reversed start order. When Module2 is a supervisor, his > children will be stopped first. > http://www.erlang.org/doc/design_principles/sup_princ.html#id69917 > > On Wed, May 4, 2011 at 10:42 AM, Martin Dimitrov wrote: > >> Hi, >> >> On application stop what is the order of termination of the supervised >> processes? >> >> For example, the supervisor's children are defined as follows: >> >> {ok, {{one_for_all, 5, 1}, >> [ >> {module1, {module1, start_link, []}, permanent, 2000, worker, >> [module1]}, >> {module2, {module2, start_link, []}, permanent, infinity, >> supervisor, [module2]}, >> {module3, {module3, start_link, []}, permanent, 2000, worker, >> [module3]} >> ] >> }}. >> >> In what order they will be terminated? Is it determined? >> >> The module2 is also a supervisor, will its children be terminated before >> proceeding with the top one? >> >> Thanks, >> >> Martin >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > From dsc@REDACTED Wed May 4 12:29:32 2011 From: dsc@REDACTED (Dave Challis) Date: Wed, 04 May 2011 11:29:32 +0100 Subject: [erlang-questions] File size limits on file:write_file and file:write? References: <4DC12A8C.5030408@ecs.soton.ac.uk> Message-ID: I'm having trouble writing large binaries to disk using file:write or file:write_file. I couldn't see any limits mentioned in the file module documentation (http://www.erlang.org/doc/man/file.html), or on the erlang limits page (http://www.erlang.org/doc/efficiency_guide/advanced.html#id67006) though. I'm trying to write a 3Gb binary to disk using: Data = <<...some 3Gb binary...>>. file:write("/tmp/foo", Data). I get the error: {error,badarg} I've checked that data is the right type: is_binary(Data) -> true byte_size(Data) -> 3200000000 If I shrink Data to less than 2Gb, the write operation works fine. Erlang is running in 64-bit mode, my erlang system info is: Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:8:8] [rq:8] [async-threads:0] [hipe] [kernel-poll:false] Is there something I should be doing differently, or a compile time option that I missed? -- Dave Challis dsc@REDACTED From carlo.bertoldi@REDACTED Wed May 4 12:53:36 2011 From: carlo.bertoldi@REDACTED (Carlo Bertoldi) Date: Wed, 04 May 2011 12:53:36 +0200 Subject: [erlang-questions] File size limits on file:write_file and file:write? In-Reply-To: References: <4DC12A8C.5030408@ecs.soton.ac.uk> Message-ID: <4DC13030.10400@ubiquity.it> On 04/05/2011 12:29, Dave Challis wrote: > I'm having trouble writing large binaries to disk using file:write or > file:write_file. > > If I shrink Data to less than 2Gb, the write operation works fine. > snip > Erlang is running in 64-bit mode, my erlang system info is: > Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:8:8] [rq:8] > [async-threads:0] [hipe] [kernel-poll:false] > > Is there something I should be doing differently, or a compile time > option that I missed? > I believe you forgot to mention the underlying filesystem you're using. The 2GB limit reminds me of a FAT filesystem. Just my 2 cents. Carlo From dsc@REDACTED Wed May 4 13:19:13 2011 From: dsc@REDACTED (Dave Challis) Date: Wed, 04 May 2011 12:19:13 +0100 Subject: [erlang-questions] File size limits on file:write_file and file:write? In-Reply-To: <4DC13030.10400@ubiquity.it> References: <4DC12A8C.5030408@ecs.soton.ac.uk> <4DC13030.10400@ubiquity.it> <4DC13631.5060608@ecs.soton.ac.uk> Message-ID: On 04/05/11 11:53, Carlo Bertoldi wrote: > On 04/05/2011 12:29, Dave Challis wrote: >> I'm having trouble writing large binaries to disk using file:write or >> file:write_file. >> >> If I shrink Data to less than 2Gb, the write operation works fine. >> > snip >> Erlang is running in 64-bit mode, my erlang system info is: >> Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:8:8] [rq:8] >> [async-threads:0] [hipe] [kernel-poll:false] >> >> Is there something I should be doing differently, or a compile time >> option that I missed? >> > I believe you forgot to mention the underlying filesystem you're using. > The 2GB limit reminds me of a FAT filesystem. Just my 2 cents. Ah, sorry. I'm trying to write to an ext4 partition, running on 64-bit Ubuntu. I can create 10Gb+ files in the directory I'm trying to write to using applications without a problem though. Thanks, -- Dave Challis dsc@REDACTED From spawn.think@REDACTED Wed May 4 13:45:08 2011 From: spawn.think@REDACTED (Ahmed Omar) Date: Wed, 4 May 2011 13:45:08 +0200 Subject: [erlang-questions] File size limits on file:write_file and file:write? In-Reply-To: References: <4DC12A8C.5030408@ecs.soton.ac.uk> <4DC13631.5060608@ecs.soton.ac.uk> <4DC13030.10400@ubiquity.it> Message-ID: file:write/2 , first argument is an io_device() not filename http://www.erlang.org/doc/man/file.html#write-2 On Wed, May 4, 2011 at 1:19 PM, Dave Challis wrote: > On 04/05/11 11:53, Carlo Bertoldi wrote: > >> On 04/05/2011 12:29, Dave Challis wrote: >> >>> I'm having trouble writing large binaries to disk using file:write or >>> file:write_file. >>> >>> If I shrink Data to less than 2Gb, the write operation works fine. >>> >>> snip >> >>> Erlang is running in 64-bit mode, my erlang system info is: >>> Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:8:8] [rq:8] >>> [async-threads:0] [hipe] [kernel-poll:false] >>> >>> Is there something I should be doing differently, or a compile time >>> option that I missed? >>> >>> I believe you forgot to mention the underlying filesystem you're using. >> The 2GB limit reminds me of a FAT filesystem. Just my 2 cents. >> > > Ah, sorry. I'm trying to write to an ext4 partition, running on 64-bit > Ubuntu. I can create 10Gb+ files in the directory I'm trying to write to > using applications without a problem though. > > Thanks, > > -- > Dave Challis > dsc@REDACTED > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think -------------- next part -------------- An HTML attachment was scrubbed... URL: From spawn.think@REDACTED Wed May 4 13:45:56 2011 From: spawn.think@REDACTED (Ahmed Omar) Date: Wed, 4 May 2011 13:45:56 +0200 Subject: [erlang-questions] File size limits on file:write_file and file:write? In-Reply-To: References: <4DC12A8C.5030408@ecs.soton.ac.uk> <4DC13631.5060608@ecs.soton.ac.uk> <4DC13030.10400@ubiquity.it> Message-ID: You wanted file:write_file/2 i guess On Wed, May 4, 2011 at 1:45 PM, Ahmed Omar wrote: > file:write/2 , first argument is an io_device() not filename > http://www.erlang.org/doc/man/file.html#write-2 > > > On Wed, May 4, 2011 at 1:19 PM, Dave Challis wrote: > >> On 04/05/11 11:53, Carlo Bertoldi wrote: >> >>> On 04/05/2011 12:29, Dave Challis wrote: >>> >>>> I'm having trouble writing large binaries to disk using file:write or >>>> file:write_file. >>>> >>>> If I shrink Data to less than 2Gb, the write operation works fine. >>>> >>>> snip >>> >>>> Erlang is running in 64-bit mode, my erlang system info is: >>>> Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:8:8] [rq:8] >>>> [async-threads:0] [hipe] [kernel-poll:false] >>>> >>>> Is there something I should be doing differently, or a compile time >>>> option that I missed? >>>> >>>> I believe you forgot to mention the underlying filesystem you're using. >>> The 2GB limit reminds me of a FAT filesystem. Just my 2 cents. >>> >> >> Ah, sorry. I'm trying to write to an ext4 partition, running on 64-bit >> Ubuntu. I can create 10Gb+ files in the directory I'm trying to write to >> using applications without a problem though. >> >> Thanks, >> >> -- >> Dave Challis >> dsc@REDACTED >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > > > -- > Best Regards, > - Ahmed Omar > http://nl.linkedin.com/in/adiaa > Follow me on twitter > @spawn_think > > -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsc@REDACTED Wed May 4 13:49:57 2011 From: dsc@REDACTED (Dave Challis) Date: Wed, 04 May 2011 12:49:57 +0100 Subject: [erlang-questions] File size limits on file:write_file and file:write? In-Reply-To: References: <4DC12A8C.5030408@ecs.soton.ac.uk> <4DC13631.5060608@ecs.soton.ac.uk> <4DC13030.10400@ubiquity.it> <4DC13D65.7010200@ecs.soton.ac.uk> Message-ID: On 04/05/11 12:45, Ahmed Omar wrote: > You wanted file:write_file/2 i guess Oops, that was a mistake in the original post. I've tried both: file:write_file("/tmp/foo", Data). and {ok, Fp} = file:open("/tmp/foo", [write]). file:write(Fp, Data). Both give {error,badarg} when Data > 2Gb, and write the file fine otherwise. Thanks, -- Dave Challis dsc@REDACTED From tony@REDACTED Wed May 4 14:33:25 2011 From: tony@REDACTED (Tony Rogvall) Date: Wed, 4 May 2011 14:33:25 +0200 Subject: [erlang-questions] File size limits on file:write_file and file:write? In-Reply-To: References: <4DC12A8C.5030408@ecs.soton.ac.uk> <4DC13631.5060608@ecs.soton.ac.uk> <4DC13030.10400@ubiquity.it> <4DC13D65.7010200@ecs.soton.ac.uk> Message-ID: On 4 maj 2011, at 13.49, Dave Challis wrote: > On 04/05/11 12:45, Ahmed Omar wrote: >> You wanted file:write_file/2 i guess > > Oops, that was a mistake in the original post. > > I've tried both: > > file:write_file("/tmp/foo", Data). > Nearly the same thing as below. > and > > {ok, Fp} = file:open("/tmp/foo", [write]). > file:write(Fp, Data). > > Both give {error,badarg} when Data > 2Gb, and write the file fine otherwise. > Looks like the problem is in beam/utils/io_list_len. io_list_len returns an int, which is 32 bit on x64_64. The return type should probably be Sint, but the all calls to io_list_len must be updated accordingly. Workaround: write in smaller chunks. /Tony "Have run Make so many times I dunno what's installed anymore" -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony@REDACTED Wed May 4 14:39:04 2011 From: tony@REDACTED (Tony Rogvall) Date: Wed, 4 May 2011 14:39:04 +0200 Subject: [erlang-questions] File size limits on file:write_file and file:write? In-Reply-To: References: <4DC12A8C.5030408@ecs.soton.ac.uk> <4DC13631.5060608@ecs.soton.ac.uk> <4DC13030.10400@ubiquity.it> <4DC13D65.7010200@ecs.soton.ac.uk> Message-ID: <1FB2EB74-2A0A-43F8-B407-2239CE88A132@rogvall.se> > > Looks like the problem is in beam/utils/io_list_len. Should be io.c/io_list_vec_len, but the problem with io_list_len remains. "Have run Make so many times I dunno what's installed anymore" -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsc@REDACTED Wed May 4 14:41:00 2011 From: dsc@REDACTED (Dave Challis) Date: Wed, 04 May 2011 13:41:00 +0100 Subject: [erlang-questions] File size limits on file:write_file and file:write? In-Reply-To: References: <4DC12A8C.5030408@ecs.soton.ac.uk> <4DC13631.5060608@ecs.soton.ac.uk> <4DC13030.10400@ubiquity.it> <4DC13D65.7010200@ecs.soton.ac.uk> <4DC1495C.6010902@ecs.soton.ac.uk> Message-ID: On 04/05/11 13:33, Tony Rogvall wrote: > > On 4 maj 2011, at 13.49, Dave Challis wrote: > >> On 04/05/11 12:45, Ahmed Omar wrote: >>> You wanted file:write_file/2 i guess >> >> Oops, that was a mistake in the original post. >> >> I've tried both: >> >> file:write_file("/tmp/foo", Data). >> > > Nearly the same thing as below. > >> and >> >> {ok, Fp} = file:open("/tmp/foo", [write]). >> file:write(Fp, Data). >> >> Both give {error,badarg} when Data > 2Gb, and write the file fine >> otherwise. >> > > > Looks like the problem is in beam/utils/io_list_len. > io_list_len returns an int, which is 32 bit on x64_64. > The return type should probably be Sint, but the all calls to > io_list_len must > be updated accordingly. > > Workaround: write in smaller chunks. Ah, thanks, this makes sense. I'd just traced the error to: erlang:iolist_to_binary([4, <<...3Gb binary...>>]). which was failing, but wasn't sure where to look for iolist_to_binary's definition in the source (I'm assuming it uses io_list_len somewhere down the line). It's something I'll watch for in future anyway, thanks again, -- Dave Challis dsc@REDACTED From sir.sedrik@REDACTED Wed May 4 15:02:33 2011 From: sir.sedrik@REDACTED (Fredrik Andersson) Date: Wed, 4 May 2011 15:02:33 +0200 Subject: [erlang-questions] Errors when generating tests for CosNotifications on windows. In-Reply-To: References: Message-ID: So here is the promised update. Changing to a path that did not truncate does not work. My guess is that because cosNotifications is truncated it fails to find the file. I have tried several of the compilers that are bootstrapped, built or downloaded from the erlang.org site. If I use any bootsrapped, self built or downloaded version of erlc I get the above error. If I use the version under otp/bin/win32 I get a message telling me that erlcexec.exe can't be found, I tried scanning my computer for it but I simply dont have it. Where is erlexec supposed to reside? On Wed, May 4, 2011 at 8:56 AM, Fredrik Andersson wrote: > The path is not longer than 256 chars. I am using the one built and > installed from source to generate the tests. > > I downloaded the latest version of cygwin when I started on this so it is > not older than a couple of weeks. The installer is reporting 2.738 back to > me. > > I currently have a new run going from a directory that has no seperate path > longer than 8 chars to avoid the truncating in paths. Will let you know how > it goes. > > > On Wed, May 4, 2011 at 12:35 AM, OvermindDL1 wrote: > >> On May 3, 2011 7:36 AM, "Niclas Eklund" wrote: >> > >> > >> > Hello! >> > >> > As you've probably guessed we don't encounter this problem. ;-) But then >> the test suites are only built once (not a Windows machine) and then re-used >> by different plattforms. Speed things up. >> > >> > Since there is a 256 chars limit (Windows paths and command line), this >> might be it. I suppose that a faulty setting of one of the Erlang related >> environment variables (e.g. ERL_TOP) could cause problems as well. Perhaps >> you can e-mail them to me? >> >> As I recall Windows has a limit if 4096 per complete path if using the NT >> api for note. 512 if 8.3 format is enabled in the registry. >> >> > >> > Due to the fact that CosNotification depends on several other >> Cos-services, more IDL files needs to be included compared with, for >> example, CosTime. >> > >> > Best Regards, >> > >> > Niclas @ Erlang/OTP >> > >> > >> > On Thu, 21 Apr 2011, Fredrik Andersson wrote: >> > >> >> On Thu, Apr 21, 2011 at 11:04 AM, Alexander Krasnukhin < >> >> the.malkolm@REDACTED> wrote: >> >> >> >>> Hi, >> >>> >> >>> It is just a guess and probably sounds stupid but could you try to >> compile >> >>> within the folder with smaller path length? >> >>> >> >> >> >> I tried moving the otp folder to / and it had no difference, I can make >> them >> >> all compile if I cp the idl files to the test folder of cosNotification >> but >> >> that seems to be a suboptimal way of doing things. >> >> >> >> >> >>> >> >>> On Thu, Apr 21, 2011 at 10:57 AM, Fredrik Andersson < >> sir.sedrik@REDACTED>wrote: >> >>> >> >>>> Hi all >> >>>> >> >>>> I want to run the test suites on my windows build but I am running >> into >> >>>> trouble when generating the tests for CosNotification. I can >> reproduce the >> >>>> error by building the tests inside of otp/lib/CosNotification/test >> using >> >>>> make tests. >> >>>> >> >>>> Can anyone help? >> >>>> >> >>>> The following is the error I get. I have verified that the idl files >> are >> >>>> present in the src directory. >> >>>> >> >>>> erlc +debug_info -pa >> >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosNotification/ebin -pa >> >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosNotification/src -pa >> >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosTime/ebin -pa >> >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosTime/include -pa >> >>>> /home/ESLbingen/bingen/tmp/otp/lib/orber/ebin -pa >> >>>> /home/ESLbingen/bingen/tmp/otp/lib/ic/ebin -pa >> >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosNotification/include >> >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosEvent/src >> >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosNotification/include -pa >> >>>> /home/ESLbingen/bingen/tmp/otp/lib/orber/include -pa >> >>>> /home/ESLbingen/bingen/tmp/otp/internal_tools/test_server/ebin -pa >> >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosNotification/ebin -pa >> >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosNotification/test/idl_output >> -pa >> >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosTime/ebin -pa >> >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosTime/include -pa >> >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosNotification/include -pa >> >>>> /home/ESLbingen/bingen/tmp/otp/lib/ic/ebin >> >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosTime/ebin >> >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosTime/include >> >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/orber/include >> >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosNotification/src >> >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosNotification/include >> >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosNotification >> >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosNotification/test/idl_output >> >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/test_server/include -oidl_output >> \ >> >>>> +'{cfgfile,"notify_test_server.cfg"}' >> >>>> notify_test_server.idl >> >>>> []: warning: unrecognised option: debug_info >> >>>> Erlang IDL compiler version 4.2.26 >> >>>> >> "c:/cygwin/home/ESLBIN~1/bingen/tmp/otp/lib/COSNOT~1/test/notify_test_server.idl": >> >>>> preprocessor error: >> >>>> >> c:/cygwin/home/ESLBIN~1/bingen/tmp/otp/lib/COSNOT~1/test/notify_test_server.idl:23: >> >>>> CosNotification.idl: No such file or directory >> >>>> >> "c:/cygwin/home/ESLBIN~1/bingen/tmp/otp/lib/COSNOT~1/test/notify_test_server.idl": >> >>>> preprocessor error: >> >>>> >> c:/cygwin/home/ESLBIN~1/bingen/tmp/otp/lib/COSNOT~1/test/notify_test_server.idl:24: >> >>>> CosNotifyComm.idl: No such file or directory >> >>>> >> "c:/cygwin/home/ESLBIN~1/bingen/tmp/otp/lib/COSNOT~1/test/notify_test_server.idl": >> >>>> 2 errors found >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> erlang-questions mailing list >> >>>> erlang-questions@REDACTED >> >>>> http://erlang.org/mailman/listinfo/erlang-questions >> >>>> >> >>>> >> >>> >> >>> >> >>> -- >> >>> Regards, >> >>> Alexander >> >>> >> >>> >> >> >> > >> > >> > _______________________________________________ >> > erlang-questions mailing list >> > erlang-questions@REDACTED >> > http://erlang.org/mailman/listinfo/erlang-questions >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgustavsson@REDACTED Wed May 4 15:12:55 2011 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Wed, 4 May 2011 15:12:55 +0200 Subject: [erlang-questions] File size limits on file:write_file and file:write? In-Reply-To: References: <4DC12A8C.5030408@ecs.soton.ac.uk> <4DC13631.5060608@ecs.soton.ac.uk> <4DC13030.10400@ubiquity.it> <4DC13D65.7010200@ecs.soton.ac.uk> Message-ID: On Wed, May 4, 2011 at 2:33 PM, Tony Rogvall wrote: > Looks like the problem is in beam/utils/io_list_len. > io_list_len returns an int, which is 32 bit on x64_64. > The return type should probably be Sint, but the all calls to io_list_len > must > be updated accordingly. We will fix that problem in R14B03. -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From sir.sedrik@REDACTED Wed May 4 15:26:47 2011 From: sir.sedrik@REDACTED (Fredrik Andersson) Date: Wed, 4 May 2011 15:26:47 +0200 Subject: [erlang-questions] Errors when generating tests for CosNotifications on windows. In-Reply-To: References: Message-ID: It should ofcourse be erlexec.exe not erlcexec.exe On Wed, May 4, 2011 at 3:02 PM, Fredrik Andersson wrote: > So here is the promised update. > > Changing to a path that did not truncate does not work. My guess is that > because cosNotifications is truncated it fails to find the file. > > I have tried several of the compilers that are bootstrapped, built or > downloaded from the erlang.org site. > > If I use any bootsrapped, self built or downloaded version of erlc I get > the above error. > > If I use the version under otp/bin/win32 I get a message telling me that > erlcexec.exe can't be found, I tried scanning my computer for it but I > simply dont have it. Where is erlexec supposed to reside? > > > > On Wed, May 4, 2011 at 8:56 AM, Fredrik Andersson wrote: > >> The path is not longer than 256 chars. I am using the one built and >> installed from source to generate the tests. >> >> I downloaded the latest version of cygwin when I started on this so it is >> not older than a couple of weeks. The installer is reporting 2.738 back to >> me. >> >> I currently have a new run going from a directory that has no seperate >> path longer than 8 chars to avoid the truncating in paths. Will let you know >> how it goes. >> >> >> On Wed, May 4, 2011 at 12:35 AM, OvermindDL1 wrote: >> >>> On May 3, 2011 7:36 AM, "Niclas Eklund" wrote: >>> > >>> > >>> > Hello! >>> > >>> > As you've probably guessed we don't encounter this problem. ;-) But >>> then the test suites are only built once (not a Windows machine) and then >>> re-used by different plattforms. Speed things up. >>> > >>> > Since there is a 256 chars limit (Windows paths and command line), this >>> might be it. I suppose that a faulty setting of one of the Erlang related >>> environment variables (e.g. ERL_TOP) could cause problems as well. Perhaps >>> you can e-mail them to me? >>> >>> As I recall Windows has a limit if 4096 per complete path if using the NT >>> api for note. 512 if 8.3 format is enabled in the registry. >>> >>> > >>> > Due to the fact that CosNotification depends on several other >>> Cos-services, more IDL files needs to be included compared with, for >>> example, CosTime. >>> > >>> > Best Regards, >>> > >>> > Niclas @ Erlang/OTP >>> > >>> > >>> > On Thu, 21 Apr 2011, Fredrik Andersson wrote: >>> > >>> >> On Thu, Apr 21, 2011 at 11:04 AM, Alexander Krasnukhin < >>> >> the.malkolm@REDACTED> wrote: >>> >> >>> >>> Hi, >>> >>> >>> >>> It is just a guess and probably sounds stupid but could you try to >>> compile >>> >>> within the folder with smaller path length? >>> >>> >>> >> >>> >> I tried moving the otp folder to / and it had no difference, I can >>> make them >>> >> all compile if I cp the idl files to the test folder of >>> cosNotification but >>> >> that seems to be a suboptimal way of doing things. >>> >> >>> >> >>> >>> >>> >>> On Thu, Apr 21, 2011 at 10:57 AM, Fredrik Andersson < >>> sir.sedrik@REDACTED>wrote: >>> >>> >>> >>>> Hi all >>> >>>> >>> >>>> I want to run the test suites on my windows build but I am running >>> into >>> >>>> trouble when generating the tests for CosNotification. I can >>> reproduce the >>> >>>> error by building the tests inside of otp/lib/CosNotification/test >>> using >>> >>>> make tests. >>> >>>> >>> >>>> Can anyone help? >>> >>>> >>> >>>> The following is the error I get. I have verified that the idl files >>> are >>> >>>> present in the src directory. >>> >>>> >>> >>>> erlc +debug_info -pa >>> >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosNotification/ebin -pa >>> >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosNotification/src -pa >>> >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosTime/ebin -pa >>> >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosTime/include -pa >>> >>>> /home/ESLbingen/bingen/tmp/otp/lib/orber/ebin -pa >>> >>>> /home/ESLbingen/bingen/tmp/otp/lib/ic/ebin -pa >>> >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosNotification/include >>> >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosEvent/src >>> >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosNotification/include -pa >>> >>>> /home/ESLbingen/bingen/tmp/otp/lib/orber/include -pa >>> >>>> /home/ESLbingen/bingen/tmp/otp/internal_tools/test_server/ebin -pa >>> >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosNotification/ebin -pa >>> >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosNotification/test/idl_output >>> -pa >>> >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosTime/ebin -pa >>> >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosTime/include -pa >>> >>>> /home/ESLbingen/bingen/tmp/otp/lib/cosNotification/include -pa >>> >>>> /home/ESLbingen/bingen/tmp/otp/lib/ic/ebin >>> >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosTime/ebin >>> >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosTime/include >>> >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/orber/include >>> >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosNotification/src >>> >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosNotification/include >>> >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosNotification >>> >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/cosNotification/test/idl_output >>> >>>> -I/home/ESLbingen/bingen/tmp/otp/lib/test_server/include >>> -oidl_output \ >>> >>>> +'{cfgfile,"notify_test_server.cfg"}' >>> >>>> notify_test_server.idl >>> >>>> []: warning: unrecognised option: debug_info >>> >>>> Erlang IDL compiler version 4.2.26 >>> >>>> >>> "c:/cygwin/home/ESLBIN~1/bingen/tmp/otp/lib/COSNOT~1/test/notify_test_server.idl": >>> >>>> preprocessor error: >>> >>>> >>> c:/cygwin/home/ESLBIN~1/bingen/tmp/otp/lib/COSNOT~1/test/notify_test_server.idl:23: >>> >>>> CosNotification.idl: No such file or directory >>> >>>> >>> "c:/cygwin/home/ESLBIN~1/bingen/tmp/otp/lib/COSNOT~1/test/notify_test_server.idl": >>> >>>> preprocessor error: >>> >>>> >>> c:/cygwin/home/ESLBIN~1/bingen/tmp/otp/lib/COSNOT~1/test/notify_test_server.idl:24: >>> >>>> CosNotifyComm.idl: No such file or directory >>> >>>> >>> "c:/cygwin/home/ESLBIN~1/bingen/tmp/otp/lib/COSNOT~1/test/notify_test_server.idl": >>> >>>> 2 errors found >>> >>>> >>> >>>> >>> >>>> _______________________________________________ >>> >>>> erlang-questions mailing list >>> >>>> erlang-questions@REDACTED >>> >>>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>>> >>> >>>> >>> >>> >>> >>> >>> >>> -- >>> >>> Regards, >>> >>> Alexander >>> >>> >>> >>> >>> >> >>> > >>> > >>> > _______________________________________________ >>> > erlang-questions mailing list >>> > erlang-questions@REDACTED >>> > http://erlang.org/mailman/listinfo/erlang-questions >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kuleshovmail@REDACTED Wed May 4 16:10:31 2011 From: kuleshovmail@REDACTED (shk) Date: Wed, 4 May 2011 07:10:31 -0700 (PDT) Subject: [erlang-questions] Erlang logging system Message-ID: <1304518231725-3495678.post@n4.nabble.com> Hello, I need in logging sub-system in my erlang project. I know that erlang has error_logger application, I want to ask community: What are you using for logging in your project? Thank you. -- View this message in context: http://erlang.2086793.n4.nabble.com/Erlang-logging-system-tp3495678p3495678.html Sent from the Erlang Questions mailing list archive at Nabble.com. From rtrlists@REDACTED Wed May 4 16:22:02 2011 From: rtrlists@REDACTED (Robert Raschke) Date: Wed, 4 May 2011 15:22:02 +0100 Subject: [erlang-questions] Erlang logging system In-Reply-To: <1304518231725-3495678.post@n4.nabble.com> References: <1304518231725-3495678.post@n4.nabble.com> Message-ID: On Wed, May 4, 2011 at 3:10 PM, shk wrote: > I need in logging sub-system in my erlang project. I know that erlang has > error_logger application, I want to ask community: What are you using for > logging in your project? > I use the error_logger in multi file mode (with some convenience macros) and a hacked rb module to read the resulting log files. The report "browser" I use includes module specific call backs for pretty-printing specific log messages (tied in with the convenience macros that generate the msgs) and no longer has any interactive components, just one shot "give me some log". Robby -------------- next part -------------- An HTML attachment was scrubbed... URL: From b.nicholson@REDACTED Wed May 4 17:00:36 2011 From: b.nicholson@REDACTED (Barry Nicholson) Date: Wed, 04 May 2011 10:00:36 -0500 Subject: [erlang-questions] Erlang logging system In-Reply-To: <1304518231725-3495678.post@n4.nabble.com> References: <1304518231725-3495678.post@n4.nabble.com> Message-ID: <4DC16A14.1010309@niceng.com> I've been using log4erl. It's not perfect but it works. Easily managed in the code. We wrote an appender that sent errors and fatals to our enterprise logging system. Very quick and easy. Only issue I have is that certain system failures we haven't been able to force from sasl through log4erl. Not sure why, it hasn't exceeded my pain level yet. Barry Nicholson On 5/4/11 9:10 AM, shk wrote: > Hello, > > I need in logging sub-system in my erlang project. I know that erlang has > error_logger application, I want to ask community: What are you using for > logging in your project? > > Thank you. > > -- > View this message in context: http://erlang.2086793.n4.nabble.com/Erlang-logging-system-tp3495678p3495678.html > Sent from the Erlang Questions mailing list archive at Nabble.com. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From watson.timothy@REDACTED Wed May 4 17:50:01 2011 From: watson.timothy@REDACTED (Tim Watson) Date: Wed, 4 May 2011 16:50:01 +0100 Subject: [erlang-questions] Erlang logging system In-Reply-To: <4DC16A14.1010309@niceng.com> References: <1304518231725-3495678.post@n4.nabble.com> <4DC16A14.1010309@niceng.com> Message-ID: https://github.com/hyperthunk/fastlog. Very simple config/api, works with error_logger under the covers. Work in progress. From vances@REDACTED Wed May 4 18:08:13 2011 From: vances@REDACTED (Vance Shipley) Date: Wed, 4 May 2011 12:08:13 -0400 Subject: [erlang-questions] child processes order of termination In-Reply-To: <4DC11169.3030507@gmail.com> References: <4DC11169.3030507@gmail.com> Message-ID: <20110504160813.GS305@h216-235-12-168.host.egate.net> On Wed, May 04, 2011 at 11:42:17AM +0300, Martin Dimitrov wrote: } On application stop what is the order of termination of the supervised } processes? The children are stopped in reverse order of starting. 1> {ok, Sup} = supervisor:start_link(super_order, [[1,2,3], [4,5,6], [7,8,9]]). init(1) init(2) init(3) init(4) init(5) init(6) init(7) init(8) init(9) {ok,<0.33.0>} 2> exit(Sup, shutdown). true terminate(9) terminate(8) terminate(7) terminate(6) terminate(5) terminate(4) terminate(3) terminate(2) terminate(1) } The module2 is also a supervisor, will its children be terminated before } proceeding with the top one? If you are sure to specify Shutdown=infinity and Type=supervisor in your child specification for the supervisor the parent supervisor will wait for it to exit before going on to shutdown the preceeding children. -- -Vance -------------- next part -------------- -module(super_order). -export([init/1]). -behaviour(supervisor). init([IdsA, IdsB, IdsC]) -> ChildSpecsA = [server_child_spec(Id) || Id <- IdsA], ChildSpecsB = [super_child_spec(IdsB)], ChildSpecsC = [server_child_spec(Id) || Id <- IdsC], ChildSpecs = ChildSpecsA ++ ChildSpecsB ++ ChildSpecsC, {ok,{{one_for_one, 10, 60}, ChildSpecs}}; init([Ids]) -> ChildSpecs = [server_child_spec(Id) || Id <- Ids], {ok,{{one_for_one, 10, 60}, ChildSpecs}}. server_child_spec(Id) -> StartMod = server_order, StartFunc = {gen_server, start_link, [StartMod, [Id], []]}, {Id, StartFunc, permanent, 4000, worker, [StartMod]}. super_child_spec(Ids) -> StartMod = super_order, StartFunc = {supervisor, start_link, [StartMod, [Ids]]}, {Ids, StartFunc, permanent, infinity, supervisor, [StartMod]}. -------------- next part -------------- -module(server_order). -behaviour(gen_server). -export([init/1, handle_call/3, handle_cast/2, handle_info/2, terminate/2, code_change/3]). init([Id]) -> io:fwrite("init(~b)~n", [Id]), process_flag(trap_exit, true), {ok, Id}. handle_cast(_, State) -> {noreply, State}. handle_call(_, _, State) -> {noreply, State}. handle_info(_, State) -> {noreply, State}. terminate(_, Id) -> io:fwrite("terminate(~b)~n", [Id]). code_change(_, State, _) -> {ok, State}. From als@REDACTED Wed May 4 20:28:17 2011 From: als@REDACTED (Anthony Shipman) Date: Thu, 5 May 2011 04:28:17 +1000 Subject: [erlang-questions] byte() vs. char() use in documentation In-Reply-To: <001901cc09cd$73653520$5a2f9f60$@com> References: <20110502091415.GA6512@erix.ericsson.se> <201105040533.58985.als@iinet.net.au> <001901cc09cd$73653520$5a2f9f60$@com> Message-ID: <201105050428.17641.als@iinet.net.au> On Wed, 4 May 2011 06:05:24 am David Mercer wrote: > On Tuesday, May 03, 2011, Anthony Shipman wrote: > > I think a more complete design would represent a character as a binary > > that is > > a UTF8 encoding of its code points. A string would then be a deep list > > of > > these binaries. > > How is that superior than representing a character by a single integer > representing the Unicode codepoint, a string by a list of characters? You > can always use unicode:characters_to_binary/1 to convert to a UTF-8 binary > if you wish. What we think of as a character, e.g. some letter on a page, can be a combination of a base component and some combining components. (I use the word component since I'm not quite sure at the moment exactly what a glyph means. A component is represented by a code point). Combining components include accents and a variety of other marks that some languages attach to the base component. For example in French the "e-acute" could be represented as a single code point or as a pair of the code points for "e" and "acute accent". The standard puts some effort into defining a canonical representation so that it isn't a total nightmare to tell if two characters are the same. You have to convert a Unicode string to its canonical form before you can test for equality. To fully implement the intent of Unicode we need to talk in terms of characters, i.e. something you may insert or delete in a word processor, which may themselves be a sequence of code points which are kept together. -- Anthony Shipman Mamas don't let your babies als@REDACTED grow up to be outsourced. From moxford@REDACTED Wed May 4 23:20:16 2011 From: moxford@REDACTED (Mike Oxford) Date: Wed, 4 May 2011 14:20:16 -0700 Subject: [erlang-questions] uds_drv strangeness Message-ID: I can local the driver, open the socket, it creates the file and I can telnet to the file, getting the expected "^]" message. However, uds_input is NEVER called even though I have not changed it in the uds_driver_entry (the file is bone-stock.) I've set dbg:p(new, [all]) in addition to trying to do it per-pid after the listener starts. Nada. gdb with a breakpoint will set but will never get hit. I am doing "telnet /tmp/erlang/mox" to the file. What obvious step am I missing here? :P TIA! -mox -------------- next part -------------- An HTML attachment was scrubbed... URL: From corticalcomputer@REDACTED Thu May 5 01:27:12 2011 From: corticalcomputer@REDACTED (G.S.) Date: Wed, 4 May 2011 16:27:12 -0700 Subject: [erlang-questions] What's the best way of producing bitmaps/pixelmaps through Erlang. Message-ID: Hello, What's the best way to produce/specify bitmaps/pixemaps using Erlang? Is anyone using particular modules, or projects for this? Thanks, -Gene -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Thu May 5 02:03:28 2011 From: ok@REDACTED (Richard O'Keefe) Date: Thu, 5 May 2011 12:03:28 +1200 Subject: [erlang-questions] byte() vs. char() use in documentation In-Reply-To: <201105040533.58985.als@iinet.net.au> References: <20110502091415.GA6512@erix.ericsson.se> <20110503094549.GA10981@erix.ericsson.se> <201105040533.58985.als@iinet.net.au> Message-ID: On 4/05/2011, at 7:33 AM, Anthony Shipman wrote: > On Tue, 3 May 2011 07:45:49 pm Raimo Niskanen wrote: >> The programmer should regard strings as a sequence of unicode code points. >> As such they are just that and there is no encoding to bother about. >> The code point number uniquely defines which unicode character it is. > > As I recall, a Unicode character can be composed of up to 7 code points. I find this rather confusing. Here are some official definitions from the Unicode standard: Character. (1) The smallest component of written language that has semantic value; refers to the abstract meaning and/or shape, rather than a specific shape (see also glyph), though in code tables some form of visual representation is essential for the reader?s understanding. (2) Synonym for abstract character. (3) The basic unit of encoding for the Unicode character encoding. (4) The English name for the ideographic written elements of Chinese origin. [See ideograph (2).] Coded Character Set. A character set in which each character is assigned a numeric code point. Frequently abbreviated as character set, charset, or code set; the acronym CCS is also used. Code Point. (1) Any value in the Unicode codespace; that is, the range of integers from 0 to 10FFFF(base 16). (See definition D10 in Section 3.4, Characters and Encoding.) (2) A value, or position, for a character, in any coded character set. Code Unit. The minimal bit combination that can represent a unit of encoded text for processing or interchange. The Unicode Standard uses 8-bit code units in the UTF-8 encoding form, 16-bit code units in the UTF-16 encoding form, and 32-bit code units in the UTF-32 encoding form. (See definition D77 in Section 3.9, Unicode Encoding Forms.) Each Unicode character has *BY DEFINITION* precisely *ONE* code point. A code point is a number in the range 0 to 1,114,111. The largest legal Unicode code point (hex 10FFFF) requires precisely FOUR code units: 11110100 10001111 10111111 10111111 ----- 3 -- 6 -- 6 -- 6 The 11110 prefix on the leading byte says "here are four bytes"; the "10" prefixes on the remaining bytes say "here are 6 more bits". No Unicode code point requires more than four code units. > To quote a text book I'm looking at now: > ------------- > The trick is, again, to disabuse yourself of the idea that a one-to-one > correspondence exists between "characters" as the user is used to thinking of > them and code points (or code units) in the backing store. Sorry, it looks as though you need a better text book. Code points and code units are NOT the same thing (at least for UTF-8 and UTF-16). There IS, by definition, a direct correspondence between Unicode characters and code points (not every code point has been assigned a character yet). > Unicode uses the > term "character" to mean more or less "the entity that's represented by a > single Unicode code point," but this concept doesn't always match the user's > definition of "character". And _that_ is talking about two other issues: (1) Unicode classifies code points as Graphic, Format, Control, Private-Use, Surrogate, Noncharacter, or Reserved. Only the Graphic characters are ones that users are likely to think of as characters. (2) Things that the user thinks of as a character (like ?) may be represented by sequences of code points, called Grapheme Clusters, consisting of a base character and some nonspacing marks. This has nothing to do with encodings. > I think a more complete design would represent a character as a binary that is > a UTF8 encoding of its code points. A string would then be a deep list of > these binaries. Once again, a Unicode character has *by definition* one code point; and from a storage point of view, it's pretty silly to use a big thing like a binary to represent a 21-bit integer. The main principle to understand about Unicode is to *always* think in terms of strings, not of characters. From dan@REDACTED Thu May 5 05:17:30 2011 From: dan@REDACTED (Daniel Dormont) Date: Wed, 4 May 2011 23:17:30 -0400 Subject: [erlang-questions] Why does fun2ms produce this particular result? In-Reply-To: References: Message-ID: On Wed, May 4, 2011 at 3:03 AM, Mazen Harake wrote: > Well, yes. > > 1) Quoting documentation: > > "ETS match specifications are there to produce a return value. Usually the > MatchBody contains one single ConditionExpression which defines the return > value without having any side effects. Calls with side effects are not > allowed in the ETS context. > > When tracing there is no return value to produce, the match specification > either matches or doesn't. The effect when the expression matches is a trace > message rather then a returned term. The ActionTerm's are executed as in > an imperative language, i.e. for their side effects. Functions with side > effects are also allowed when tracing. > > In ETS the match head is a tuple() (or a single match variable) while it > is a list (or a single match variable) when tracing." > So in other words (in the context of dbg): yes, it is a list because you > can have several "actions" in it. But in the context of ets there is usually > only 1 namely what you want to return, if you have more than 1 then the last > one will be returned. > > Got it. > 2) This is correct. > > I would say the opposite; I see it as semantics of both are similar enough > to use a "mini language" with exceptions rather than 2 different > specifications all together, but I guess that is just a matter of personal > taste. > > /M > > > Fair enough. So far the trick I've been using is to write my function out, use fun2ms in a shell to generate the MatchSpec, copy that into my code and leave the original function as a comment. This works well enough for me. dan > > On 4 May 2011 05:18, Daniel Dormont wrote: > >> Thanks, let me summarize to see if this is correct: >> >> 1) In general (though not in the case of ETS/Mnesia), the MatchBody might >> contain actions to be performed before returning the final result. This is >> why it's a list. >> 2) Actions may be specified in the form of a tuple, the first element of >> which describes the action to be performed. Therefore, if you want to have >> your "action" be a value which is itself a tuple, you have to wrap it in >> another tuple. >> >> Is this right? If so, I guess I understand what the rules are, but I'm >> still not really clear on why, since it seems like dbg and ets are different >> enough that you'd never really use the same kind of MatchSpec for both, so >> there isn't much benefit in having the structure be compatible. >> >> dan >> >> On Mon, May 2, 2011 at 2:35 AM, Mazen Harake wrote: >> >>> Check out chapter 2 in my dbg tutorial, it describes matchspecs and how >>> to use them. You will also understand what it is that fun2ms actually >>> translates to. >>> >>> >>> http://www.erlang-factory.com/conference/testingtutorialworkshop2010/speakers/MazenHarake >>> >>> Dbg matchspecs aren't exactly like the mnesia ones, there is a small >>> difference but the concept is exactly the same. >>> >>> /M >>> >>> On 1 May 2011 21:06, Daniel Dormont wrote: >>> >>>> I'm trying to get the hang of match specs. Here's a pretty simple one >>>> but it has a feature I'm not getting. It's intended for use with Mnesia: >>>> >>>> 1> rd(person, {name, address, email, phone}). >>>> person >>>> 2> ets:fun2ms(fun(#person{name=Name, email=Email}) -> {Name, Email} >>>> end). >>>> [{#person{name = '$1',address = '_',email = '$2', >>>> phone = '_'}, >>>> [], >>>> [{{'$1','$2'}}]}] >>>> >>>> My first question was going to be why the whole thing is a >>>> single-element list, but I think I figured that out: it's because there >>>> could be multiple clauses of the match as a whole. The part I don't get is >>>> in the result: [{{'$1','$2'}}] >>>> >>>> 1) Why is it a list at all, since a particular head in the function can >>>> only have one result? >>>> 2) Why does the tuple have to be wrapped in another tuple? ie why isn't >>>> it just {'$1','$2'} >>>> >>>> For now I'm happy to just trust that fun2ms works, but I'd like to >>>> understand it a little better. >>>> >>>> thanks, >>>> Dan >>>> >>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>>> >>> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From masklinn@REDACTED Thu May 5 08:03:32 2011 From: masklinn@REDACTED (Masklinn) Date: Thu, 5 May 2011 08:03:32 +0200 Subject: [erlang-questions] byte() vs. char() use in documentation In-Reply-To: References: <20110502091415.GA6512@erix.ericsson.se> <20110503094549.GA10981@erix.ericsson.se> <201105040533.58985.als@iinet.net.au> Message-ID: On 2011-05-05, at 02:03 , Richard O'Keefe wrote: > On 4/05/2011, at 7:33 AM, Anthony Shipman wrote: > >> On Tue, 3 May 2011 07:45:49 pm Raimo Niskanen wrote: >>> The programmer should regard strings as a sequence of unicode code points. >>> As such they are just that and there is no encoding to bother about. >>> The code point number uniquely defines which unicode character it is. >> >> As I recall, a Unicode character can be composed of up to 7 code points. > > I find this rather confusing. > Here are some official definitions from the Unicode standard: > > Character. > (1) The smallest component of written language that has semantic value; > refers to the abstract meaning and/or shape, rather than a specific > shape (see also glyph), though in code tables some form of visual > representation is essential for the reader?s understanding. > (2) Synonym for abstract character. > (3) The basic unit of encoding for the Unicode character encoding. > (4) The English name for the ideographic written elements of Chinese origin. > [See ideograph (2).] > > Coded Character Set. > A character set in which each character is assigned a numeric code point. > Frequently abbreviated as character set, charset, or code set; > the acronym CCS is also used. > > Code Point. > (1) Any value in the Unicode codespace; that is, the range of integers > from 0 to 10FFFF(base 16). > (See definition D10 in Section 3.4, Characters and Encoding.) > (2) A value, or position, for a character, in any coded character set. > > Code Unit. > The minimal bit combination that can represent a unit of encoded text > for processing or interchange. The Unicode Standard uses 8-bit code units > in the UTF-8 encoding form, 16-bit code units in the UTF-16 encoding form, > and 32-bit code units in the UTF-32 encoding form. > (See definition D77 in Section 3.9, Unicode Encoding Forms.) > > Each Unicode character has *BY DEFINITION* precisely *ONE* code point. > A code point is a number in the range 0 to 1,114,111. > > The largest legal Unicode code point (hex 10FFFF) requires precisely > FOUR code units: > > 11110100 10001111 10111111 10111111 > ----- 3 -- 6 -- 6 -- 6 > > The 11110 prefix on the leading byte says "here are four bytes"; > the "10" prefixes on the remaining bytes say "here are 6 more bits". UTF-8 makes allowance for full 31 bits code points (6 code units when encoded) though, which may trip people up. > No Unicode code point requires more than four code units. For now. > And _that_ is talking about two other issues: I strongly disagree. I believe this is the *core* of the whole issue, and *this* is the reason why people are confused: a complete mastery of the unicode lingo (which the standard's definitions does not even provide, as you mentioned in your comment "Character has 4 different definitions, most of which can not be understood by the lay man) and a very good capacity to differentiate common speech and unicode lingo are necessary to navigate unicode discussions correctly. The vast majority of developers do *not* possess these (not necessarily for lack of trying), and the differences in the status of (mostly) the word "character" (which can be hard to understand from context) lead to a minefield of misunderstanding and frustration. I strongly believe it was a mistake for the Unicode consortium to use this word. From chad@REDACTED Thu May 5 08:26:13 2011 From: chad@REDACTED (Chad DePue) Date: Thu, 5 May 2011 03:26:13 -0300 Subject: [erlang-questions] Erlang logging system In-Reply-To: References: <1304518231725-3495678.post@n4.nabble.com> <4DC16A14.1010309@niceng.com> Message-ID: In the interests of bike shedding a bit here, we noticed a substantial performance hit for a client application that logged using error_logger so we wrote a simple log framework that uses macros to allow the caller to compile out the log statements at runtime for critical modules. You could extend it to also log to other logs like log4erl, fastlog, etc. Just the overhead of building the strings for the log, even if you aren't writing them out, can be quite expensive... https://github.com/elbrujohalcon/elog Chad DePue skype: cdepue inakanetworks.com On Wed, May 4, 2011 at 12:50 PM, Tim Watson wrote: > https://github.com/hyperthunk/fastlog. Very simple config/api, works > with error_logger under the covers. Work in progress. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lionel.cons@REDACTED Thu May 5 09:16:39 2011 From: lionel.cons@REDACTED (Lionel Cons) Date: Thu, 5 May 2011 09:16:39 +0200 Subject: [erlang-questions] byte() vs. char() use in documentation In-Reply-To: <20110504075734.GA16456@erix.ericsson.se> (Raimo Niskanen's message of "Wed, 4 May 2011 09:57:34 +0200") References: <20110502091415.GA6512@erix.ericsson.se> <20110503094549.GA10981@erix.ericsson.se> <201105040533.58985.als@iinet.net.au> <20110504075734.GA16456@erix.ericsson.se> Message-ID: AFAIK, the confusion comes from two different uses of the term "character". The "individual character" is at the heart of Unicode. Each individual character maps to a unique code point. For instance, a lowercase alpha is the character named "GREEK SMALL LETTER ALPHA" and maps to code point U+03B1. The Unicode code points are between 0 and 0x10FFFF. The "logical character" is what human beings usually have in mind. In the real world, a text is a sequence of logical characters. An example of such a character is the lowercase letter "e" with an acute accent. Some logical characters do not map directly to individual characters and must be represented as a combination of several individual characters (this is called I think an "extended grapheme cluster"). Some logical characters do map to individual characters and can therefore have two different representations in Unicode: - with an individual character - with a combination of several individual characters For instance, our "e" with an acute accent can be represented as: - the individual character "LATIN SMALL LETTER E WITH ACUTE" (U+00E9) or - the combination "LATIN SMALL LETTER E" (U+0065) plus "COMBINING ACUTE ACCENT" (U+0301) To cope with this, Unicode defines the notions of canonical and compatible equivalence (see http://en.wikipedia.org/wiki/Unicode_equivalence). To come back to the point, we have to define what we mean with the Erlang char() type: - if it's an individual character then it can naturally be represented as a single integer for its code point - if it's a logical character then it has to be a list of integers In any case, the language must provide specific functions to work on strings and characters. For instance, a logical character comparison must take into account the Unicode equivalence. Cheers, __________________________________________________________ Lionel Cons http://cern.ch/lionel.cons CERN http://cern.ch From chad@REDACTED Thu May 5 09:34:35 2011 From: chad@REDACTED (Chad DePue) Date: Thu, 5 May 2011 04:34:35 -0300 Subject: [erlang-questions] Encrypting/Decrypting data In-Reply-To: References: <5E0A3E92-4D97-432C-A882-E9F1CF45C61E@jkemp.net> Message-ID: I would strongly recommend reading Bruce Schneier's Practical Cryptography - it is absolutely invaluable for building this type of system. Then, I'd suggest reading Hacker News and searching for posts by tptacek http://news.ycombinator.com/user?id=tptacek - his warnings regarding building your own encryption system - even by just cobbling together secure algorithms - should not be taken lightly. His most famous post on the subject is "If you're typing the letters A-E-S into your code you're doing it wrong" is worth reading. http://chargen.matasano.com/chargen/2009/7/22/if-youre-typing-the-letters-a-e-s-into-your-code-youre-doing.html Best, Chad DePue skype: cdepue inakanetworks.com On Sat, Apr 30, 2011 at 10:12 PM, Chris Hicks wrote: > That certainly makes sense, and is a lot simpler than anything I was > coming up with in my head. Thank you. > > > Subject: Re: [erlang-questions] Encrypting/Decrypting data > > From: john@REDACTED > > Date: Sat, 30 Apr 2011 20:31:47 -0400 > > CC: erlang-questions@REDACTED > > To: silent_vendetta@REDACTED > > > > > Chris, > > > > On Apr 30, 2011, at 6:25 PM, Chris Hicks wrote: > > > > > This is a bit more of a general question than Erlang specific but I > hope someone here can answer this, or simply point me to a place where it > has already been answered. > > > > > > I'm writing a server in which I will be storing encrypted user data > (unlike Sony). My problem is probably a product of zero experience with > encryption combined with a lack of sleep, but I can't figure out how to do > this securely. By that I mean I understand how to use crypto to > encrypt/decrypt a piece of data but the Key and the Ivec have to be the same > for both the encryption and decryption otherwise it doesn't work...so how do > I make this happen without storing those two things "out in the open?" It > seems like that can't be the optimal solution since anyone who could just > grab those and decrypt the data. Am I missing something completely obvious? > > > > You have it correct. The solution to your problem is to do what things > like 'ssh' or Apache 'httpd' do, and use a key stored in a file with > user-restricted permissions, which requires a passphrase to read. As your > server starts, it will ask the user who starts it for the passphrase and > then read the key. > > > > Regards, > > > > - John Kemp > > > > > > > > Chris Hicks. > > > > > > > > > _______________________________________________ > > > erlang-questions mailing list > > > erlang-questions@REDACTED > > > http://erlang.org/mailman/listinfo/erlang-questions > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.arnon@REDACTED Thu May 5 09:40:34 2011 From: alex.arnon@REDACTED (Alex Arnon) Date: Thu, 5 May 2011 10:40:34 +0300 Subject: [erlang-questions] Looking for RDBMS driver with Transaction Support. In-Reply-To: References: Message-ID: Oh, excellent! Thank you very much! On Tue, May 3, 2011 at 3:39 PM, mabrek wrote: > On Mon, May 2, 2011 at 10:24 PM, Alex Arnon wrote: > > Hi All, > > > > Is there an RDBMS driver in the Erlang universe whose API supports > > transactions? > > The docs for odbc, epgsql and emysql do not specify any kind of > transaction > > support. > > epgsql does have simple transaction support, take a look at function > with_transaction/2 at > https://github.com/wg/epgsql/blob/master/src/pgsql.erl > > Regards, > Anton Lebedevich > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimo+erlang-questions@REDACTED Thu May 5 09:49:21 2011 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Thu, 5 May 2011 09:49:21 +0200 Subject: [erlang-questions] byte() vs. char() use in documentation In-Reply-To: References: <20110502091415.GA6512@erix.ericsson.se> <20110503094549.GA10981@erix.ericsson.se> <201105040533.58985.als@iinet.net.au> <20110504075734.GA16456@erix.ericsson.se> Message-ID: <20110505074921.GA21532@erix.ericsson.se> On Thu, May 05, 2011 at 09:16:39AM +0200, Lionel Cons wrote: > AFAIK, the confusion comes from two different uses of the term "character". > > The "individual character" is at the heart of Unicode. Each individual > character maps to a unique code point. For instance, a lowercase alpha is > the character named "GREEK SMALL LETTER ALPHA" and maps to code point > U+03B1. The Unicode code points are between 0 and 0x10FFFF. > > The "logical character" is what human beings usually have in mind. In the > real world, a text is a sequence of logical characters. An example of such > a character is the lowercase letter "e" with an acute accent. > > Some logical characters do not map directly to individual characters and > must be represented as a combination of several individual characters (this > is called I think an "extended grapheme cluster"). > > Some logical characters do map to individual characters and can therefore > have two different representations in Unicode: > - with an individual character > - with a combination of several individual characters > > For instance, our "e" with an acute accent can be represented as: > - the individual character "LATIN SMALL LETTER E WITH ACUTE" (U+00E9) > or > - the combination "LATIN SMALL LETTER E" (U+0065) plus "COMBINING ACUTE > ACCENT" (U+0301) > > To cope with this, Unicode defines the notions of canonical and compatible > equivalence (see http://en.wikipedia.org/wiki/Unicode_equivalence). > > To come back to the point, we have to define what we mean with the Erlang > char() type: > - if it's an individual character then it can naturally be represented as > a single integer for its code point > - if it's a logical character then it has to be a list of integers The Erlang char() type today must then according to your excellent clarification be defined as a Unicode individual character, range 0 upto 0x10FFFF (there are invalid values, right). > > In any case, the language must provide specific functions to work on strings > and characters. For instance, a logical character comparison must take into > account the Unicode equivalence. That is as far as I know unimplemented funcionality. Some may fit into the unicode module, and some might be left to a text processing application to implement. Just to implement Unicode equivalence sounds complicated and as a moving target, or somthing best implemented by OS libraries. > > Cheers, > __________________________________________________________ > Lionel Cons http://cern.ch/lionel.cons > CERN http://cern.ch > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From masklinn@REDACTED Thu May 5 10:08:12 2011 From: masklinn@REDACTED (Masklinn) Date: Thu, 5 May 2011 10:08:12 +0200 Subject: [erlang-questions] byte() vs. char() use in documentation In-Reply-To: References: <20110502091415.GA6512@erix.ericsson.se> <20110503094549.GA10981@erix.ericsson.se> <201105040533.58985.als@iinet.net.au> <20110504075734.GA16456@erix.ericsson.se> Message-ID: On 2011-05-05, at 09:16 , Lionel Cons wrote: > > In any case, the language must provide specific functions to work on strings > and characters. For instance, a logical character comparison must take into > account the Unicode equivalence. And more generally UTS #10 "UCA" (Unicode Collation Algorithm), which is kind of a bloody pain [0, 1] (note how 6 months elapsed between the first post and the second one) and handles many more things than equivalences. [0] http://useless-factor.blogspot.com/2007/10/unicode-implementers-guide-part-5.html [1] http://useless-factor.blogspot.com/2008/05/unicode-collation-works-now.html From watson.timothy@REDACTED Thu May 5 10:27:46 2011 From: watson.timothy@REDACTED (Tim Watson) Date: Thu, 5 May 2011 09:27:46 +0100 Subject: [erlang-questions] Erlang logging system In-Reply-To: References: <1304518231725-3495678.post@n4.nabble.com> <4DC16A14.1010309@niceng.com> Message-ID: On 5 May 2011 07:26, Chad DePue wrote: > In the interests of bike shedding a bit here, we noticed a substantial > performance hit for a client application that logged using error_logger so > we wrote a simple log framework that uses macros to allow the caller to > compile out the log statements at runtime for critical modules. You could > extend it to also log to other logs like log4erl, fastlog, etc. Just the > overhead of building the strings for the log, even if you aren't writing > them out, can be quite expensive... > https://github.com/elbrujohalcon/elog > Chad DePue > skype: cdepue > inakanetworks.com > Interesting. Fastlog doesn't build any string formats unless the logging level you've asked for (on the specific "named" logger) is active, although there will be a couple of function calls and a message to one of the logger gen_server processes, but no actual write to error_logger takes place unless the level is "switched on". It does sound like compiling out even the unnecessary calls would be use for, as you put it, very critical modules. I'm also hoping to put disk_log support in to fastlog later on, as I understand it's the most efficient mechanism available (bar using macros to avoid logging at all). From mikhail.sobolev@REDACTED Thu May 5 10:37:27 2011 From: mikhail.sobolev@REDACTED (Mikhail Sobolev) Date: Thu, 5 May 2011 11:37:27 +0300 Subject: [erlang-questions] pattern matching vs proplists vs dict performance Message-ID: Hi, We have a lot of proplists, where the keys (atoms) need to be converted to strings. The first idea was to create another proplist with the necessary mapping and write a function that would do the things. After considering it for a while (without actually writing any code :)), Erlang pattern matching came to mind. After looking around a bit I saw statements like "for rather short proplists (10s of elements), the speed will be pretty much the same". We have 10s of thousands of documents that require this kind of conversion and this conversion has to be done fast. So I decided to write a little benchmark[1], which gave the definitive answer: pattern matching is much faster (times on the test machine): * proplists -- ~4.9s * dicts -- ~3.0s * case inside the function -- ~0.86s * case as a separate function -- ~0.89s We have discussed the results and started to wonder: 1) are we doing something wrong? (we are all newbies in here) 2) why there's such a big difference in time? (proplists module provides BIFs, right?) 3) are there any other ways to do what we want? The current inclination is to generate a function based on the mapping and then utilize the produced function to do the job. Any answers/comments/suggestions? :) -- Misha [1] https://gist.github.com/956717 From masklinn@REDACTED Thu May 5 10:57:20 2011 From: masklinn@REDACTED (Masklinn) Date: Thu, 5 May 2011 10:57:20 +0200 Subject: [erlang-questions] byte() vs. char() use in documentation In-Reply-To: <20110505074921.GA21532@erix.ericsson.se> References: <20110502091415.GA6512@erix.ericsson.se> <20110503094549.GA10981@erix.ericsson.se> <201105040533.58985.als@iinet.net.au> <20110504075734.GA16456@erix.ericsson.se> <20110505074921.GA21532@erix.ericsson.se> Message-ID: <065D7456-DE4E-40FF-81E9-ED0002B27550@masklinn.net> On 2011-05-05, at 09:49 , Raimo Niskanen wrote: >> In any case, the language must provide specific functions to work on strings >> and characters. For instance, a logical character comparison must take into >> account the Unicode equivalence. > > That is as far as I know unimplemented funcionality. Some may fit into > the unicode module, and some might be left to a text processing application > to implement. Just to implement Unicode equivalence sounds complicated > and as a moving target Unicode is generally complicated, but it's also well-defined. The hard part is creating the correct generator from the UC's data (and following format evolutions), but the moving target itself (the spec) should mostly be auto-tracked by the extractor/generator > or somthing best implemented by OS libraries. As far as I know, no OS provides that service. The only widespread low-level Unicode library is ICU[0]. And it's both pretty old and pretty big. [0] http://en.wikipedia.org/wiki/International_Components_for_Unicode From dmercer@REDACTED Thu May 5 16:12:26 2011 From: dmercer@REDACTED (David Mercer) Date: Thu, 5 May 2011 09:12:26 -0500 Subject: [erlang-questions] byte() vs. char() use in documentation In-Reply-To: <065D7456-DE4E-40FF-81E9-ED0002B27550@masklinn.net> References: <20110502091415.GA6512@erix.ericsson.se> <20110503094549.GA10981@erix.ericsson.se> <201105040533.58985.als@iinet.net.au> <20110504075734.GA16456@erix.ericsson.se> <20110505074921.GA21532@erix.ericsson.se> <065D7456-DE4E-40FF-81E9-ED0002B27550@masklinn.net> Message-ID: <000701cc0b2e$7719c340$654d49c0$@com> In the past few days, various people wrote: > [Various stuff debating Unicode, characters, glyphs, codepoints, code units, bits, bytes, strings, iolists, etc. etc.] I think most programmers are content treating each Unicode codepoint as a "character," regardless of whether that is strictly correct or not. It is the unit that is strung together to make strings. A list of Unicode codepoints seems the reasonable canonical way of representing strings. Thus: char() :: 0..16#10ffff string() :: [char()] The only issue is in the encoding of strings into binary formats, and this becomes relevant when you have iolists, which mix string pieces with encoded string pieces (binaries). If anyone ever wants to decode an iolist into a straight string (if this is ever done), it seems reasonable to let the user specify the encoding of the binaries within the iolist. On the other hand, if someone is converting an iolist into an encoded binary, we can either (1) assume the binaries in the iolist are already in the target encoding, (2) let the programmer specify the encoding of the source iolist binaries and have them automatically converted to the target encoding. The advantage of the former is that it allows iolists to represent more than just strings: they could represent strings with embedded binary components (where character encoding is irrelevant). There's nothing that says every binary in an iolist has to decode into a string. I'm going to put that in all-caps for emphasis: THERE'S NOTHING THAT SAYS EVERY BINARY IN AN IOLIST HAS TO DECODE INTO A STRING. Thus, I would assume iolists are defined as: iolist() :: [char() | binary() | iolist()] and we have functions available in some library somewhere: iolist_to_string(iolist(), SourceEncoding) -> string() iolist_to_binary(iolist(), TargetEncoding) -> binary(). (You'd probably also have iolist_to_string/1 and iolist_to_binary/1, which assume UTF-8.) We *might* also want to define an iolist_to_binary/3, which does convert binaries in the iolist from one encoding to another, but I'd consider that optional. Anyone disagree? Cheers, DBM From nick@REDACTED Thu May 5 16:13:10 2011 From: nick@REDACTED (Niclas Eklund) Date: Thu, 5 May 2011 16:13:10 +0200 Subject: [erlang-questions] SSH-2.0.6 is available Message-ID: Hello! A memory leak has been sealed in the SSH application. If you use it you should upgrade as soon as possible (at the latest when R14B03 is released within a few weeks). You can find it via Github: https://github.com/erlang/otp/commit/b39153c1db8e311e6fb759f7c778b10340902890 Note, it depends on some new functions in Crypto. Hence, you must add this as well: https://github.com/erlang/otp/commit/f228601de45c5b53241b103af6616453c50885a5 Since it's impossible how many uses this application, it would be nice if you could reply to this mail (to me only) what you use it for. A general description is good enough. TIA! Best Regards, Niclas @ Erlang/OTP From dmercer@REDACTED Thu May 5 16:25:07 2011 From: dmercer@REDACTED (David Mercer) Date: Thu, 5 May 2011 09:25:07 -0500 Subject: [erlang-questions] pattern matching vs proplists vs dict performance In-Reply-To: References: Message-ID: <000801cc0b30$3ca05ce0$b5e116a0$@com> On Thursday, May 05, 2011, Mikhail Sobolev wrote: > We have 10s of thousands of documents that require this kind of > conversion and this conversion has to be done fast. So I decided to > write a little benchmark[1], which gave the definitive answer: pattern > matching is much faster (times on the test machine): > * proplists -- ~4.9s > * dicts -- ~3.0s > * case inside the function -- ~0.86s > * case as a separate function -- ~0.89s > > We have discussed the results and started to wonder: > > 1) are we doing something wrong? (we are all newbies in here) I don't think so. I'd expect pattern matching in a case or function to be faster than iterating through a data structure, regardless of whether the data structure is a proplist or dict. > 2) why there's such a big difference in time? (proplists module > provides BIFs, right?) Again, I don't think so. I consider proplists to be Erlang-only, and I'd be surprised if it were implemented in C. Regardless, I'd still expect pattern matching to be faster. > 3) are there any other ways to do what we want? You could look them up in ETS tables. ETS *is* in written in C, so it *might* be faster than proplists and dicts, but I still wouldn't expect it to be faster than pattern-matching. Benchmark to prove me right or wrong. > The current inclination is to generate a function based on the mapping > and then utilize the produced function to do the job. If 3-5s is unacceptable, but 0.9s is OK, that's the way I'd go, so long as you're not changing the atom-to-string mapping very often (requiring regeneration/recompilation of the function). If 3-5s is OK, however, I'd concentrate on other problems. Cheers, DBM From masklinn@REDACTED Thu May 5 16:36:56 2011 From: masklinn@REDACTED (Masklinn) Date: Thu, 5 May 2011 16:36:56 +0200 Subject: [erlang-questions] byte() vs. char() use in documentation In-Reply-To: <000701cc0b2e$7719c340$654d49c0$@com> References: <20110502091415.GA6512@erix.ericsson.se> <20110503094549.GA10981@erix.ericsson.se> <201105040533.58985.als@iinet.net.au> <20110504075734.GA16456@erix.ericsson.se> <20110505074921.GA21532@erix.ericsson.se> <065D7456-DE4E-40FF-81E9-ED0002B27550@masklinn.net> <000701cc0b2e$7719c340$654d49c0$@com> Message-ID: <76F9F655-91D4-46C5-BF7A-B8193630C427@masklinn.net> On 2011-05-05, at 16:12 , David Mercer wrote: > In the past few days, various people wrote: > >> [Various stuff debating Unicode, characters, glyphs, codepoints, code > units, bits, bytes, strings, iolists, etc. etc.] > > I think most programmers are content treating each Unicode codepoint as a > "character," regardless of whether that is strictly correct or not. It is > the unit that is strung together to make strings. A list of Unicode > codepoints seems the reasonable canonical way of representing strings. > Thus: > > char() :: 0..16#10ffff > string() :: [char()] It's the only way, but you can not manipulate a unicode string as a list because it's *broken*. Sure, you don't realize it if you're an english-speaking developer working only with english speakers. But that does not make it not-broken. And what "most developers" are content with has never been very high praises. You'd think a dweller of the Erlang mailing list would be the first to know it: most programmers are also content using threads and locks, regardless of whether that's strictly correct or not. From silent_vendetta@REDACTED Thu May 5 17:15:30 2011 From: silent_vendetta@REDACTED (Chris Hicks) Date: Thu, 5 May 2011 08:15:30 -0700 Subject: [erlang-questions] Encrypting/Decrypting data In-Reply-To: References: , <5E0A3E92-4D97-432C-A882-E9F1CF45C61E@jkemp.net>, , Message-ID: I will certainly look into those things, thank you. From: chad@REDACTED Date: Thu, 5 May 2011 04:34:35 -0300 Subject: Re: [erlang-questions] Encrypting/Decrypting data To: silent_vendetta@REDACTED CC: erlang-questions@REDACTED I would strongly recommend reading Bruce Schneier's Practical Cryptography - it is absolutely invaluable for building this type of system. Then, I'd suggest reading Hacker News and searching for posts by tptacek http://news.ycombinator.com/user?id=tptacek - his warnings regarding building your own encryption system - even by just cobbling together secure algorithms - should not be taken lightly. His most famous post on the subject is "If you're typing the letters A-E-S into your code you're doing it wrong" is worth reading. http://chargen.matasano.com/chargen/2009/7/22/if-youre-typing-the-letters-a-e-s-into-your-code-youre-doing.html Best,Chad DePue skype: cdepue inakanetworks.com On Sat, Apr 30, 2011 at 10:12 PM, Chris Hicks wrote: That certainly makes sense, and is a lot simpler than anything I was coming up with in my head. Thank you. > Subject: Re: [erlang-questions] Encrypting/Decrypting data > From: john@REDACTED > Date: Sat, 30 Apr 2011 20:31:47 -0400 > CC: erlang-questions@REDACTED > To: silent_vendetta@REDACTED > > Chris, > > On Apr 30, 2011, at 6:25 PM, Chris Hicks wrote: > > > This is a bit more of a general question than Erlang specific but I hope someone here can answer this, or simply point me to a place where it has already been answered. > > > > I'm writing a server in which I will be storing encrypted user data (unlike Sony). My problem is probably a product of zero experience with encryption combined with a lack of sleep, but I can't figure out how to do this securely. By that I mean I understand how to use crypto to encrypt/decrypt a piece of data but the Key and the Ivec have to be the same for both the encryption and decryption otherwise it doesn't work...so how do I make this happen without storing those two things "out in the open?" It seems like that can't be the optimal solution since anyone who could just grab those and decrypt the data. Am I missing something completely obvious? > > You have it correct. The solution to your problem is to do what things like 'ssh' or Apache 'httpd' do, and use a key stored in a file with user-restricted permissions, which requires a passphrase to read. As your server starts, it will ask the user who starts it for the passphrase and then read the key. > > Regards, > > - John Kemp > > > > > Chris Hicks. > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From als@REDACTED Thu May 5 18:44:44 2011 From: als@REDACTED (Anthony Shipman) Date: Fri, 6 May 2011 02:44:44 +1000 Subject: [erlang-questions] byte() vs. char() use in documentation In-Reply-To: <76F9F655-91D4-46C5-BF7A-B8193630C427@masklinn.net> References: <20110502091415.GA6512@erix.ericsson.se> <000701cc0b2e$7719c340$654d49c0$@com> <76F9F655-91D4-46C5-BF7A-B8193630C427@masklinn.net> Message-ID: <201105060244.44654.als@iinet.net.au> On Fri, 6 May 2011 12:36:56 am Masklinn wrote: > > ??????char() :: 0..16#10ffff > > ??????string() :: [char()] > > It's the only way, but you can not manipulate a unicode string as a list > because it's *broken*. Sure, you don't realize it if you're an > english-speaking developer working only with english speakers. But that > does not make it not-broken. > > And what "most developers" are content with has never been very high > praises. You'd think a dweller of the Erlang mailing list would be the > first to know it: most programmers are also content using threads and > locks, regardless of whether that's strictly correct or not. I imagine an API providing for: iterating over the string returning a sequence of bytes (e.g. UTF8); iterating over the string returning a sequence of code points; iterating over the string returning a sequence of normalised composite characters each perhaps in the form of a binary. The input to the iterators could be a deep list but what would the parts be? We could decide that an integer in the list is a code point and a binary is a UTF8 sequence. Would it be saner to require that the binary decode to whole composite characters? There could be a variety of functions for different ways of interpreting the input. -- Anthony Shipman Mamas don't let your babies als@REDACTED grow up to be outsourced. From dmercer@REDACTED Thu May 5 19:07:24 2011 From: dmercer@REDACTED (David Mercer) Date: Thu, 5 May 2011 12:07:24 -0500 Subject: [erlang-questions] byte() vs. char() use in documentation In-Reply-To: <76F9F655-91D4-46C5-BF7A-B8193630C427@masklinn.net> References: <20110502091415.GA6512@erix.ericsson.se> <20110503094549.GA10981@erix.ericsson.se> <201105040533.58985.als@iinet.net.au> <20110504075734.GA16456@erix.ericsson.se> <20110505074921.GA21532@erix.ericsson.se> <065D7456-DE4E-40FF-81E9-ED0002B27550@masklinn.net> <000701cc0b2e$7719c340$654d49c0$@com> <76F9F655-91D4-46C5-BF7A-B8193630C427@masklinn.net> Message-ID: <005701cc0b46$e879bb90$b96d32b0$@com> On Thursday, May 05, 2011, Masklinn wrote: > It's the only way, but you can not manipulate a unicode string as a > list > because it's *broken*. Sure, you don't realize it if you're an > english-speaking developer working only with english speakers. But that > does not make it not-broken. That's a fair criticism. As an English-speaker myself, I guess I would need a concrete example of something that "breaks" Unicode. I realize that some functions like "length" and "reverse" may not work so well with a broken Unicode standard, but I don't really think those come into play in real-world scenarios. The only times I would really need to know the length of a string are either to compute storage requirements (in which case strings as a list of Unicode points is pretty much exactly what I want), or to measure actual physical size a string will take up on the screen or paper. For that, I also would probably be feeding the Unicode codepoints into the font definition files to compute advance widths and bounding boxes, etc., so again I don't *really* need to understand what a character *really* is, just what will work. As for reversing a string, I'm not sure that that has ever been useful to me. Is there a concrete example that we native-English-speakers could understand so we can completely understand the issues you foreigners have? > And what "most developers" are content with has never been very high > praises. You'd think a dweller of the Erlang mailing list would be the > first to know it: most programmers are also content using threads and > locks, regardless of whether that's strictly correct or not. That's also a fair criticism. I guess what I really meant is that "for all practical purposes" strings as lists of Unicode codepoints will work. Again, I *tried* to learn French and Mandarin when I was younger, but it didn't stick, and this was before the computer era, anyway, so I was drawing the Chinese characters by hand (which is harder than it looks, by the way) rather than typing them into a computer, so I really have very little exposure to these pathological languages that break Unicode. French, I don't think, breaks the one-character-one-Unicode-codepoint rule. I know I can type French words like "gar?on" and "for?t" with all those foreign-looking squiggles around letters without a problem, and I'm pretty sure they "reverse" and "strlen" fine, too. So does anyone have an example I can wrap my head around? Thanks, y'all. Cheers, DBM From masklinn@REDACTED Thu May 5 19:24:57 2011 From: masklinn@REDACTED (Masklinn) Date: Thu, 5 May 2011 19:24:57 +0200 Subject: [erlang-questions] byte() vs. char() use in documentation In-Reply-To: <201105060244.44654.als@iinet.net.au> References: <20110502091415.GA6512@erix.ericsson.se> <000701cc0b2e$7719c340$654d49c0$@com> <76F9F655-91D4-46C5-BF7A-B8193630C427@masklinn.net> <201105060244.44654.als@iinet.net.au> Message-ID: <51388105-D82F-4EB1-94E6-F9E16A5DAF92@masklinn.net> On 2011-05-05, at 18:44 , Anthony Shipman wrote: > On Fri, 6 May 2011 12:36:56 am Masklinn wrote: >>> char() :: 0..16#10ffff >>> string() :: [char()] >> >> It's the only way, but you can not manipulate a unicode string as a list >> because it's *broken*. Sure, you don't realize it if you're an >> english-speaking developer working only with english speakers. But that >> does not make it not-broken. >> >> And what "most developers" are content with has never been very high >> praises. You'd think a dweller of the Erlang mailing list would be the >> first to know it: most programmers are also content using threads and >> locks, regardless of whether that's strictly correct or not. > > I imagine an API providing for: > iterating over the string returning a sequence of bytes (e.g. UTF8); An encoding API returning a bytes stream would probably be a better idea (UTF-8 is a valid encoding but not the only one) > iterating over the string returning a sequence of code points; > > iterating over the string returning a sequence of normalised composite > characters each perhaps in the form of a binary. A fully opaque representation of a grapheme cluster, with a relevant set of manipulators for that cluster, would likely be a good idea. The normalization of the backing code points sequence should not even be relevant (note: I may be mistaken) if the entities you're manipulating entities at the grapheme cluster level. From igarai@REDACTED Thu May 5 19:49:13 2011 From: igarai@REDACTED (=?UTF-8?B?ScOxYWtpIEdhcmF5?=) Date: Thu, 5 May 2011 14:49:13 -0300 Subject: [erlang-questions] pattern matching vs proplists vs dict performance In-Reply-To: <000801cc0b30$3ca05ce0$b5e116a0$@com> References: <000801cc0b30$3ca05ce0$b5e116a0$@com> Message-ID: On Thu, May 5, 2011 at 11:25, David Mercer wrote: > On Thursday, May 05, 2011, Mikhail Sobolev wrote: > >> We have 10s of thousands of documents that require this kind of >> conversion and this conversion has to be done fast. ?So I decided to >> write a little benchmark[1], which gave the definitive answer: pattern >> matching is much faster (times on the test machine): >> ? * proplists -- ~4.9s >> ? * dicts -- ~3.0s >> ? * case inside the function -- ~0.86s >> ? * case as a separate function -- ~0.89s >> >> We have discussed the results and started to wonder: >> >> 1) are we doing something wrong? (we are all newbies in here) > > I don't think so. ?I'd expect pattern matching in a case or function to be > faster than iterating through a data structure, regardless of whether the > data structure is a proplist or dict. > >> 2) why there's such a big difference in time? (proplists module >> provides BIFs, right?) > > Again, I don't think so. ?I consider proplists to be Erlang-only, and I'd be > surprised if it were implemented in C. ?Regardless, I'd still expect pattern > matching to be faster. You can find the code to the proplists module in /usr/lib/erlang/lib/stdlib-1.17.1/src/proplists.erl (or the equivalent directory in your system). -- I?aki Garay. From mikhail.sobolev@REDACTED Thu May 5 21:04:23 2011 From: mikhail.sobolev@REDACTED (Mikhail Sobolev) Date: Thu, 5 May 2011 22:04:23 +0300 Subject: [erlang-questions] pattern matching vs proplists vs dict performance In-Reply-To: <4DC2E901.9060402@dev-extend.eu> References: <4DC2E901.9060402@dev-extend.eu> Message-ID: Hi Lo?c, On 5 May 2011 21:14, Lo?c Hoguin wrote: > On 05/05/2011 10:37 AM, Mikhail Sobolev wrote: >> We have 10s of thousands of documents that require this kind of >> conversion and this conversion has to be done fast. ?So I decided to >> write a little benchmark[1], which gave the definitive answer: pattern >> matching is much faster (times on the test machine): >> ? * proplists -- ~4.9s >> ? * dicts -- ~3.0s >> ? * case inside the function -- ~0.86s >> ? * case as a separate function -- ~0.89s >> >> We have discussed the results and started to wonder: >> >> 1) are we doing something wrong? (we are all newbies in here) > > You should also try: > ?{atom, Value} lists:keyfind(atom, 1, List). Thanks for the suggestion. I tried it and it indeed wins over proplists. But loses to dict and the rest. > And, possibly with a little more processing: > ?atom_to_list(atom). Could you please elaborate? Why converting an atom to a list might help? > But pattern matching should still be faster because it can be optimized > at compile-time. Aha. >> 2) why there's such a big difference in time? (proplists module >> provides BIFs, right?) > > No. But lists:keyfind should be a BIF. The proplists module isn't > designed to be fast. Thank you. So our understanding was wrong. Good to know. >> 3) are there any other ways to do what we want? >> >> The current inclination is to generate a function based on the mapping >> and then utilize the produced function to do the job. > > If your keys are known in advance you should definitely use pattern > matching. In a sense, yes, they are. So we'll go with this approach. -- Misha From torben.lehoff@REDACTED Thu May 5 21:09:35 2011 From: torben.lehoff@REDACTED (Torben Hoffmann) Date: Thu, 5 May 2011 21:09:35 +0200 Subject: [erlang-questions] pattern matching vs proplists vs dict performance In-Reply-To: References: <4DC2E901.9060402@dev-extend.eu> Message-ID: On Thu, May 5, 2011 at 21:04, Mikhail Sobolev wrote: > Hi Lo?c, > > > >> 2) why there's such a big difference in time? (proplists module > >> provides BIFs, right?) > bifs_in_release() -> xref:start(s). xref:add_release(s,"c:/Program\ Files/erl5.7.4/",[{builtins,true}]). {ok,Bifs} = xref:q(s,"B"). Bifs. This will give you all BIFs in the release. Change the path according to your set-up or take the path as an argument to the function. Cheers, Torben -- http://www.linkedin.com/in/torbenhoffmann -------------- next part -------------- An HTML attachment was scrubbed... URL: From als@REDACTED Thu May 5 21:22:02 2011 From: als@REDACTED (Anthony Shipman) Date: Fri, 6 May 2011 05:22:02 +1000 Subject: [erlang-questions] byte() vs. char() use in documentation In-Reply-To: <005701cc0b46$e879bb90$b96d32b0$@com> References: <20110502091415.GA6512@erix.ericsson.se> <76F9F655-91D4-46C5-BF7A-B8193630C427@masklinn.net> <005701cc0b46$e879bb90$b96d32b0$@com> Message-ID: <201105060522.03056.als@iinet.net.au> On Fri, 6 May 2011 03:07:24 am David Mercer wrote: > That's also a fair criticism. ?I guess what I really meant is that "for all > practical purposes" strings as lists of Unicode codepoints will work. Suppose you were writing a word processor. Your software would be operating at the level of composite characters. Actions like insert and delete would work at the level of composite characters. The position of the cursor would be counted as the number of composite characters from the beginning of the buffer. A composite character is one or more code points. -- Anthony Shipman Mamas don't let your babies als@REDACTED grow up to be outsourced. From steve@REDACTED Thu May 5 23:06:22 2011 From: steve@REDACTED (Steve Strong) Date: Thu, 5 May 2011 23:06:22 +0200 Subject: [erlang-questions] Webmachine / Mochiweb & client certificates Message-ID: <001681FA23024B9AB05D80F310FD0057@srstrong.com> Hi, Does anyone out there have any experience with Webmachine (or mochiweb) and authentication using client certificates? I've had a good google around but can't see anything that's pointing me in the right direction. Getting regular SSL up & running was pretty straightforward, as is performing basic or digest authentication. I've also quite easily used curl to exchange a client key, which appeared to be successful, but within my webmachine resource I can't see anyway to see that a client cert was presented, nor any details about it that would allow me to authenticate the user or not. Any help would be much appreciated, Cheers, Steve -- Steve Strong, Director, id3as twitter.com/srstrong -------------- next part -------------- An HTML attachment was scrubbed... URL: From cw@REDACTED Thu May 5 23:17:37 2011 From: cw@REDACTED (Christian Westbrook) Date: Thu, 05 May 2011 14:17:37 -0700 Subject: [erlang-questions] Erlounge SF/Bay: 7:30 tonight (5/5) in SOMA Message-ID: <4DC313F1.9050504@props.org> Just a reminder to all who may be in the San Francisco bay area -- you are invited to: -=- Keep Your Head Out of the Cloud with Erlang -=- Join us this evening for a special ErLounge. We've the honor of being joined by two very brave guest speakers: * Patrick Sullivan (of 2600, our generous host) will share their experiences using erlang in VoIP * Michael Truog, creator of the CloudI framework (cloudi.org) has the low-down on latest developments on CloudI ( and if we can coerce him, perhaps even a demo! ;) ) time: 7:30pm location: 2600 Headquarters (SOMA) 116 Natoma Street, 2nd floor SF, CA 94105 Street parking is available; public transit always works. For more info or to RSVP: meetup.com/ErLounge See you tonight, Christian Christian Westbrook Erlanguatan, CoTweet cw@REDACTED / cw@REDACTED / @cdubs From moxford@REDACTED Thu May 5 23:34:33 2011 From: moxford@REDACTED (Mike Oxford) Date: Thu, 5 May 2011 14:34:33 -0700 Subject: [erlang-questions] Erlounge SF/Bay: 7:30 tonight (5/5) in SOMA In-Reply-To: <4DC313F1.9050504@props.org> References: <4DC313F1.9050504@props.org> Message-ID: We shneeds to finds sha ways ta get 'dis meetup out of da shitty. Traffics and parkings and schuch...schuck, espeshally durink da wushour. Wantin' ta go, but can't drag mashelf up to the shitty and dealio with all the crap that goes along wish going up dere. Going to da shitty isha pain in da arse... :) -mox On Thu, May 5, 2011 at 2:17 PM, Christian Westbrook wrote: > Just a reminder to all who may be in the San Francisco bay area -- you are > invited to: > > -=- Keep Your Head Out of the Cloud with Erlang -=- > > Join us this evening for a special ErLounge. We've the honor of being > joined by two very brave guest speakers: > > * Patrick Sullivan (of 2600, our generous host) > will share their experiences using erlang in VoIP > > * Michael Truog, creator of the CloudI framework (cloudi.org) > has the low-down on latest developments on CloudI > ( and if we can coerce him, perhaps even a demo! ;) ) > > time: 7:30pm > > location: 2600 Headquarters (SOMA) > > 116 Natoma Street, 2nd floor > > SF, CA 94105 > > Street parking is available; public transit always works. > > > For more info or to RSVP: meetup.com/ErLounge > > > See you tonight, > Christian > > > > Christian Westbrook > Erlanguatan, CoTweet > cw@REDACTED / cw@REDACTED / @cdubs > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sasa555@REDACTED Fri May 6 00:02:45 2011 From: sasa555@REDACTED (sasa) Date: Fri, 06 May 2011 00:02:45 +0200 Subject: [erlang-questions] mochiweb https/ssl Message-ID: <1304632965.1894.13.camel@sasa-laptop> Hello, First of all, I apologize if this question occurs twice. I have tried submitting it couple of hours ago via google groups, but it didn't show up, so I'm trying via e-mail now. I am trying to develop https comet (long polling) server using mochiweb. I have already written one such http server which is in production for couple of months and serves no more than 1000 concurrent users, sending broadcast message to all concurrent users at an average rate of 0.3 broadcast/sec When I added ssl support, it essentially works when smaller number of users (about 100-200) are connected. With larger number, it stops responding correctly i.e. some connection attempts are refused, requests time out etc. Only ssl/https part seems to be affected by this behavior. To better test this, I developed small test mochiweb app which works as follows: 1. Spawn and register singleton broadcast process 2. For each request, the erlang process sends its pid to the broadcast process. Then it waits for the message from the broadcast process 3. Every 5 seconds broadcast process notifies all registered https response processes from 2, then it clears its list of registered processes 4. When process from 2 receives notification, it responds and finishes. In this test implementation, the response is hardcoded short string. For the sake of brevity, I didn't include the test app code, but if necessary I can do so. I then deployed this test app to the server, and set up two client machines to load test the server. The load testing code is also written in erlang, and is using ibrowse for making https requests, since I had some problems with httpc. The test client basically adheres to the protocol described above. It spawns request processes, with each process making the requests in an infinite loop. I gather success/failure stats in a singleton erlang process and print them out in regular intervals. As in the production system, with http, the test server performs correctly. With https, when number of concurrent requests reaches some treshold (about 1000), many requests are not served. On the client machine, I occasionally receive following errors: =ERROR REPORT==== ** State machine <0.17592.0> terminating ** Reason for termination = ** {badarg,[{erlang,byte_size,[undefined]}, {ssl_tls1,split_secret,1}, {ssl_tls1,prf,4}, {ssl_handshake,master_secret,4}, {ssl_connection,handle_resumed_session,2}, {ssl_connection,next_state,3}, {gen_fsm,handle_msg,7}, {proc_lib,init_p_do_apply,3}]} While on the server I occasionally notice following errors: =SUPERVISOR REPORT==== 5-May-2011::11:06:33 === Supervisor: {local,ssl_connection_sup} Context: child_terminated Reason: {{badmatch,{resumed,undefined}}, [{ssl_handshake,hello,4}, {ssl_connection,hello,2}, {ssl_connection,next_state,3}, {gen_fsm,handle_msg,7}, {proc_lib,init_p_do_apply,3}]} Offender: [{pid,<0.7044.2>}, {name,undefined}, {mfargs,{ssl_connection,start_link,undefined}}, {restart_type,temporary}, {shutdown,4000}, {child_type,worker}] I have tried to tweak some OS parameters, as well as erlang parameters, but without success. After three days of experimenting, I am out of ideas and need some help or pointers. I am using Erlang R14B02 on 64 bit Ubuntu 10.04, all the machines are on the EC2 cloud. Following are sysctl.conf settings (I tried some more combinations without success): net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216 net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_mem = 50576 64768 98152 net.core.netdev_max_backlog = 2500 net.ipv4.netfilter.ip_conntrack_max = 1048576 net.ipv4.ip_local_port_range = 1024 65535 net.ipv4.tcp_fin_timeout = 10 Following is ulimit -a output: core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 20 file size (blocks, -f) unlimited pending signals (-i) 16382 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 32000 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) unlimited virtual memory (kbytes, -v) unlimited file locks (-x) unlimited These are mochiweb parameters: [ {port, 9999}, {name, https_test}, {ssl, true}, {ssl_opts, [ {cacertfile, "keys/cacert.pem"}, {certfile, "keys/cert.pem"}, {keyfile, "keys/cert.key"}, {depth, 0} ]} ] To use it on a 443 port, I have set up iptables port forwarding iptables -t nat -I PREROUTING --source 0/0 --destination 0/0 -p tcp --dport 443 -j REDIRECT --to-ports 9999 These are erl parameters: erl -P 268435456 -env ERL_MAX_PORTS 100000 If anybody has any idea, I would be most grateful. Best regards, Sasa -------------- next part -------------- An HTML attachment was scrubbed... URL: From travis.jensen@REDACTED Fri May 6 00:43:45 2011 From: travis.jensen@REDACTED (Travis Jensen) Date: Thu, 5 May 2011 16:43:45 -0600 Subject: [erlang-questions] Building erlang tests Message-ID: I'm trying to get the Erlang unit tests running under Linux (pu branch). I've gone through a full compile and then did "make release_tests". I'm getting the following output. Is there anywhere with instructions about how to really get the unit tests working? The wiki on github isn't cutting it for me. Thanks. tj travis@REDACTED:~/src/main-otp$ make release_tests if test -f lib/test_server/Makefile; then \ (cd lib/test_server; make TESTROOT=/home/travis/src/main-otp/release/tests release_tests) || exit $?; \ fi make[1]: Entering directory `/home/travis/src/main-otp/lib/test_server' === Entering application test_server make[2]: Entering directory `/home/travis/src/main-otp/lib/test_server/src' make -w RELEASE_PATH=/home/travis/src/main-otp/release/tests release_tests_spec make[3]: Entering directory `/home/travis/src/main-otp/lib/test_server/src' /usr/bin/install -c -d /home/travis/src/main-otp/release/tests/test_server /usr/bin/install -c -m 644 test_server_ctrl.erl test_server_node.erl test_server.erl test_server_sup.erl test_server_line.erl test_server_h.erl erl2html2.erl vxworks_client.erl ts.erl ts_run.erl ts_reports.erl ts_lib.erl ts_make.erl ts_erl_config.erl ts_autoconf_win32.erl ts_autoconf_vxworks.erl ts_install.erl ts_install_cth.erl \ ../include/test_server.hrl ../include/test_server_line.hrl test_server_internal.hrl ts.hrl \ ../ebin/ts.beam ../ebin/ts_run.beam ../ebin/ts_reports.beam ../ebin/ts_lib.beam ../ebin/ts_make.beam ../ebin/ts_erl_config.beam ../ebin/ts_autoconf_win32.beam ../ebin/ts_autoconf_vxworks.beam ../ebin/ts_install.beam ../ebin/ts_install_cth.beam \ configure.in conf_vars.in cross.cover ts.config ts.unix.config ts.win32.config \ /home/travis/src/main-otp/release/tests/test_server /usr/bin/install -c configure config.sub config.guess install-sh /home/travis/src/main-otp/release/tests/test_server make[3]: Leaving directory `/home/travis/src/main-otp/lib/test_server/src' make[2]: Leaving directory `/home/travis/src/main-otp/lib/test_server/src' make[2]: Entering directory `/home/travis/src/main-otp/lib/test_server/doc/src' make -w RELEASE_PATH=/home/travis/src/main-otp/release/tests release_tests_spec make[3]: Entering directory `/home/travis/src/main-otp/lib/test_server/doc/src' make[3]: Nothing to be done for `release_tests_spec'. make[3]: Leaving directory `/home/travis/src/main-otp/lib/test_server/doc/src' make[2]: Leaving directory `/home/travis/src/main-otp/lib/test_server/doc/src' === Leaving application test_server make[1]: Leaving directory `/home/travis/src/main-otp/lib/test_server' if test -f lib/asn1/test/Makefile; then \ (cd lib/asn1/test; make TESTROOT=/home/travis/src/main-otp/release/tests release_tests) || exit $?; \ fi make[1]: Entering directory `/home/travis/src/main-otp/lib/asn1/test' make -w RELEASE_PATH=/home/travis/src/main-otp/release/tests release_tests_spec make[2]: Entering directory `/home/travis/src/main-otp/lib/asn1/test' /usr/bin/install -c -d /home/travis/src/main-otp/release/tests/asn1_test /usr/bin/install -c -d /home/travis/src/main-otp/release/tests/asn1_test/asn1_SUITE_data /usr/bin/install -c -d /home/travis/src/main-otp/release/tests/asn1_test/asn1_bin_SUITE_data /usr/bin/install -c -d /home/travis/src/main-otp/release/tests/asn1_test/asn1_bin_v2_SUITE_data /usr/bin/install -c -m 644 h323test.erl choice_extension.erl ber_decode_error.erl testExternal.erl testPrim.erl testPrimStrings.erl testCompactBitString.erl testPrimExternal.erl testChoPrim.erl testChoExtension.erl testChoExternal.erl testChoOptional.erl testChoOptionalImplicitTag.erl testChoRecursive.erl testChoTypeRefCho.erl testChoTypeRefPrim.erl testChoTypeRefSeq.erl testChoTypeRefSet.erl testConstraints.erl testDef.erl testOpt.erl testSeqDefault.erl testSeqExtension.erl testSeqExternal.erl testSeqOptional.erl testSeq2738.erl testSeqPrim.erl testSeqTag.erl testSeqTypeRefCho.erl testSeqTypeRefPrim.erl testSeqTypeRefSeq.erl testSeqTypeRefSet.erl testSeqIndefinite.erl testSeqOf.erl testSeqOfIndefinite.erl testSeqOfCho.erl testSeqOfExternal.erl testSeqOfTag.erl testSetDefault.erl testSetExtension.erl testSetExternal.erl testSetOptional.erl testSetPrim.erl testSetTag.erl testSetTypeRefCho.erl testSetTypeRefPrim.erl testSetTypeRefSeq.erl testSetTypeRefSet.erl testSetIndefinite.erl testChoiceIndefinite.erl testSetOf.erl testSetOfCho.erl testSetOfExternal.erl testSetOfTag.erl testEnumExt.erl testInfObjectClass.erl testInfObj.erl testParameterizedInfObj.erl testMergeCompile.erl testDeepTConstr.erl testTimer.erl testRANAP.erl testMegaco.erl testMvrasn6.erl testSeqSetDefaultVal.erl testParamBasic.erl testContextSwitchingTypes.erl testTypeValueNotation.erl testOpenTypeImplicitTag.erl testROSE.erl testINSTANCE_OF.erl test_partial_incomplete_decode.erl testDER.erl test_selective_decode.erl test_special_decode_performance.erl testTCAP.erl testSSLspecs.erl test_driver_load.erl testSelectionTypes.erl test_undecoded_rest.erl test_inline.erl testTcapsystem.erl testNBAPsystem.erl test_bad_values.erl test_compile_options.erl testDoubleEllipses.erl test_modified_x420.erl testX420.erl test_x691.erl asn1_test_lib.erl asn1_app_test.erl asn1_appup_test.erl asn1_wrapper.erl asn1_SUITE.erl asn1_bin_SUITE.erl asn1_bin_v2_SUITE.erl External.hrl /home/travis/src/main-otp/release/tests/asn1_test /usr/bin/install -c -m 644 asn1.spec asn1.cover /home/travis/src/main-otp/release/tests/asn1_test chmod -R u+w /home/travis/src/main-otp/release/tests/asn1_test cd asn1_SUITE_data; tar cfh /home/travis/src/main-otp/release/tests/asn1_test/asn1_SUITE_data.tar * cd /home/travis/src/main-otp/release/tests/asn1_test/asn1_SUITE_data; tar xf /home/travis/src/main-otp/release/tests/asn1_test/asn1_SUITE_data.tar cd /home/travis/src/main-otp/release/tests/asn1_test/asn1_bin_SUITE_data; tar xf /home/travis/src/main-otp/release/tests/asn1_test/asn1_SUITE_data.tar cd /home/travis/src/main-otp/release/tests/asn1_test/asn1_bin_v2_SUITE_data; tar xf /home/travis/src/main-otp/release/tests/asn1_test/asn1_SUITE_data.tar rm /home/travis/src/main-otp/release/tests/asn1_test/asn1_SUITE_data.tar make[2]: Leaving directory `/home/travis/src/main-otp/lib/asn1/test' make[1]: Leaving directory `/home/travis/src/main-otp/lib/asn1/test' if test -f lib/common_test/test/Makefile; then \ (cd lib/common_test/test; make TESTROOT=/home/travis/src/main-otp/release/tests release_tests) || exit $?; \ fi make[1]: Entering directory `/home/travis/src/main-otp/lib/common_test/test' make -w RELEASE_PATH=/home/travis/src/main-otp/release/tests release_tests_spec make[2]: Entering directory `/home/travis/src/main-otp/lib/common_test/test' /usr/bin/install -c -d /home/travis/src/main-otp/release/tests/common_test_test /usr/bin/install -c -m 644 ct_test_support.erl ct_test_support_eh.erl ct_userconfig_callback.erl ct_smoke_test_SUITE.erl ct_event_handler_SUITE.erl ct_groups_test_1_SUITE.erl ct_groups_test_2_SUITE.erl ct_sequence_1_SUITE.erl ct_repeat_1_SUITE.erl ct_testspec_1_SUITE.erl ct_skip_SUITE.erl ct_error_SUITE.erl ct_test_server_if_1_SUITE.erl ct_config_SUITE.erl ct_master_SUITE.erl ct_misc_1_SUITE.erl ct_hooks_SUITE.erl /home/travis/src/main-otp/release/tests/common_test_test /usr/bin/install -c -m 644 common_test.spec /home/travis/src/main-otp/release/tests/common_test_test chmod -R u+w /home/travis/src/main-otp/release/tests/common_test_test make[2]: Leaving directory `/home/travis/src/main-otp/lib/common_test/test' make[1]: Leaving directory `/home/travis/src/main-otp/lib/common_test/test' if test -f lib/compiler/test/Makefile; then \ (cd lib/compiler/test; make TESTROOT=/home/travis/src/main-otp/release/tests release_tests) || exit $?; \ fi make[1]: Entering directory `/home/travis/src/main-otp/lib/compiler/test' make -w RELEASE_PATH=/home/travis/src/main-otp/release/tests release_tests_spec make[2]: Entering directory `/home/travis/src/main-otp/lib/compiler/test' /home/travis/src/main-otp/make/make_emakefile +debug_info -I/home/travis/src/main-otp/lib/test_server/include +clint -o. andor_SUITE apply_SUITE beam_validator_SUITE bs_bincomp_SUITE bs_bit_binaries_SUITE bs_construct_SUITE bs_match_SUITE bs_utf_SUITE core_fold_SUITE compile_SUITE compilation_SUITE core_SUITE error_SUITE float_SUITE fun_SUITE guard_SUITE inline_SUITE lc_SUITE match_SUITE misc_SUITE num_bif_SUITE pmod_SUITE parteval_SUITE receive_SUITE record_SUITE trycatch_SUITE warnings_SUITE test_lib \ > Emakefile /home/travis/src/main-otp/make/make_emakefile +no_copt +no_postopt +debug_info -I/home/travis/src/main-otp/lib/test_server/include +clint \ -o. andor_no_opt_SUITE apply_no_opt_SUITE bs_construct_no_opt_SUITE bs_match_no_opt_SUITE bs_utf_no_opt_SUITE core_fold_no_opt_SUITE float_no_opt_SUITE fun_no_opt_SUITE guard_no_opt_SUITE lc_no_opt_SUITE match_no_opt_SUITE misc_no_opt_SUITE num_bif_no_opt_SUITE receive_no_opt_SUITE record_no_opt_SUITE trycatch_no_opt_SUITE >> Emakefile /home/travis/src/main-otp/make/make_emakefile +no_copt +debug_info -I/home/travis/src/main-otp/lib/test_server/include +clint \ -o. andor_post_opt_SUITE apply_post_opt_SUITE bs_construct_post_opt_SUITE bs_match_post_opt_SUITE bs_utf_post_opt_SUITE core_fold_post_opt_SUITE float_post_opt_SUITE fun_post_opt_SUITE guard_post_opt_SUITE lc_post_opt_SUITE match_post_opt_SUITE misc_post_opt_SUITE num_bif_post_opt_SUITE receive_post_opt_SUITE record_post_opt_SUITE trycatch_post_opt_SUITE >> Emakefile /home/travis/src/main-otp/make/make_emakefile +inline +debug_info -I/home/travis/src/main-otp/lib/test_server/include +clint \ -o. andor_inline_SUITE apply_inline_SUITE bs_bincomp_inline_SUITE bs_bit_binaries_inline_SUITE bs_construct_inline_SUITE bs_match_inline_SUITE bs_utf_inline_SUITE core_fold_inline_SUITE float_inline_SUITE fun_inline_SUITE guard_inline_SUITE lc_inline_SUITE match_inline_SUITE misc_inline_SUITE num_bif_inline_SUITE receive_inline_SUITE record_inline_SUITE >> Emakefile /usr/bin/install -c -d /home/travis/src/main-otp/release/tests/compiler_test /usr/bin/install -c -m 644 compiler.spec compiler.cover \ Emakefile andor_SUITE.erl apply_SUITE.erl beam_validator_SUITE.erl bs_bincomp_SUITE.erl bs_bit_binaries_SUITE.erl bs_construct_SUITE.erl bs_match_SUITE.erl bs_utf_SUITE.erl core_fold_SUITE.erl compile_SUITE.erl compilation_SUITE.erl core_SUITE.erl error_SUITE.erl float_SUITE.erl fun_SUITE.erl guard_SUITE.erl inline_SUITE.erl lc_SUITE.erl match_SUITE.erl misc_SUITE.erl num_bif_SUITE.erl pmod_SUITE.erl parteval_SUITE.erl receive_SUITE.erl record_SUITE.erl trycatch_SUITE.erl warnings_SUITE.erl test_lib.erl bs_shadowed_size_var.core nested_call_in_case.core /home/travis/src/main-otp/release/tests/compiler_test /usr/bin/install -c -m 644 andor_no_opt_SUITE.erl apply_no_opt_SUITE.erl bs_construct_no_opt_SUITE.erl bs_match_no_opt_SUITE.erl bs_utf_no_opt_SUITE.erl core_fold_no_opt_SUITE.erl float_no_opt_SUITE.erl fun_no_opt_SUITE.erl guard_no_opt_SUITE.erl lc_no_opt_SUITE.erl match_no_opt_SUITE.erl misc_no_opt_SUITE.erl num_bif_no_opt_SUITE.erl receive_no_opt_SUITE.erl record_no_opt_SUITE.erl trycatch_no_opt_SUITE.erl andor_post_opt_SUITE.erl apply_post_opt_SUITE.erl bs_construct_post_opt_SUITE.erl bs_match_post_opt_SUITE.erl bs_utf_post_opt_SUITE.erl core_fold_post_opt_SUITE.erl float_post_opt_SUITE.erl fun_post_opt_SUITE.erl guard_post_opt_SUITE.erl lc_post_opt_SUITE.erl match_post_opt_SUITE.erl misc_post_opt_SUITE.erl num_bif_post_opt_SUITE.erl receive_post_opt_SUITE.erl record_post_opt_SUITE.erl trycatch_post_opt_SUITE.erl \ andor_inline_SUITE.erl apply_inline_SUITE.erl bs_bincomp_inline_SUITE.erl bs_bit_binaries_inline_SUITE.erl bs_construct_inline_SUITE.erl bs_match_inline_SUITE.erl bs_utf_inline_SUITE.erl core_fold_inline_SUITE.erl float_inline_SUITE.erl fun_inline_SUITE.erl guard_inline_SUITE.erl lc_inline_SUITE.erl match_inline_SUITE.erl misc_inline_SUITE.erl num_bif_inline_SUITE.erl receive_inline_SUITE.erl record_inline_SUITE.erl /home/travis/src/main-otp/release/tests/compiler_test chmod -R u+w /home/travis/src/main-otp/release/tests/compiler_test make[2]: Leaving directory `/home/travis/src/main-otp/lib/compiler/test' make[1]: Leaving directory `/home/travis/src/main-otp/lib/compiler/test' if test -f lib/cosEventDomain/test/Makefile; then \ (cd lib/cosEventDomain/test; make TESTROOT=/home/travis/src/main-otp/release/tests release_tests) || exit $?; \ fi make[1]: Entering directory `/home/travis/src/main-otp/lib/cosEventDomain/test' make -w RELEASE_PATH=/home/travis/src/main-otp/release/tests release_tests_spec make[2]: Entering directory `/home/travis/src/main-otp/lib/cosEventDomain/test' /usr/bin/install -c -d /home/travis/src/main-otp/release/tests/cosEventDomain_test /usr/bin/install -c -m 644 cosEventDomain.spec \ cosEventDomain.cover event_domain_SUITE.erl generated_SUITE.erl /home/travis/src/main-otp/release/tests/cosEventDomain_test /usr/bin/install -c -m 644 event_domain_SUITE.beam generated_SUITE.beam /home/travis/src/main-otp/release/tests/cosEventDomain_test make[2]: Leaving directory `/home/travis/src/main-otp/lib/cosEventDomain/test' make[1]: Leaving directory `/home/travis/src/main-otp/lib/cosEventDomain/test' if test -f lib/cosEvent/test/Makefile; then \ (cd lib/cosEvent/test; make TESTROOT=/home/travis/src/main-otp/release/tests release_tests) || exit $?; \ fi make[1]: Entering directory `/home/travis/src/main-otp/lib/cosEvent/test' make -w RELEASE_PATH=/home/travis/src/main-otp/release/tests release_tests_spec make[2]: Entering directory `/home/travis/src/main-otp/lib/cosEvent/test' /usr/bin/install -c -d /home/travis/src/main-otp/release/tests/cosEvent_test /usr/bin/install -c -m 644 event_test_server.idl cosEvent.spec \ cosEvent.cover event_test_PushC_impl.erl event_test_PullC_impl.erl event_test_PushS_impl.erl event_test_PullS_impl.erl event_channel_SUITE.erl generated_SUITE.erl /home/travis/src/main-otp/release/tests/cosEvent_test /usr/bin/install -c -m 644 event_test_PushC_impl.beam event_test_PullC_impl.beam event_test_PushS_impl.beam event_test_PullS_impl.beam event_channel_SUITE.beam generated_SUITE.beam /home/travis/src/main-otp/release/tests/cosEvent_test /usr/bin/install -c -d /home/travis/src/main-otp/release/tests/cosEvent_test/idl_output /usr/bin/install -c -m 644 idl_output/event_test_PullC.beam idl_output/event_test_PushS.beam idl_output/event_test_PullS.beam idl_output/oe_event_test_server.beam idl_output/event_test_PushC.beam idl_output/event_test.hrl idl_output/event_test_PushC.hrl idl_output/event_test_PullC.hrl idl_output/event_test_PushS.hrl idl_output/event_test_PullS.hrl idl_output/oe_event_test_server.hrl idl_output/event_test_PullC.erl idl_output/event_test_PushS.erl idl_output/event_test_PullS.erl idl_output/oe_event_test_server.erl idl_output/event_test_PushC.erl \ /home/travis/src/main-otp/release/tests/cosEvent_test/idl_output make[2]: Leaving directory `/home/travis/src/main-otp/lib/cosEvent/test' make[1]: Leaving directory `/home/travis/src/main-otp/lib/cosEvent/test' if test -f lib/cosFileTransfer/test/Makefile; then \ (cd lib/cosFileTransfer/test; make TESTROOT=/home/travis/src/main-otp/release/tests release_tests) || exit $?; \ fi make[1]: Entering directory `/home/travis/src/main-otp/lib/cosFileTransfer/test' make -w RELEASE_PATH=/home/travis/src/main-otp/release/tests release_tests_spec make[2]: Entering directory `/home/travis/src/main-otp/lib/cosFileTransfer/test' /usr/bin/install -c -d /home/travis/src/main-otp/release/tests/cosFileTransfer_test /usr/bin/install -c -m 644 cosFileTransfer.spec \ cosFileTransfer.cover fileTransfer_SUITE.erl /home/travis/src/main-otp/release/tests/cosFileTransfer_test /usr/bin/install -c -m 644 fileTransfer_SUITE.beam /home/travis/src/main-otp/release/tests/cosFileTransfer_test chmod -R u+w /home/travis/src/main-otp/release/tests/cosFileTransfer_test make[2]: Leaving directory `/home/travis/src/main-otp/lib/cosFileTransfer/test' make[1]: Leaving directory `/home/travis/src/main-otp/lib/cosFileTransfer/test' if test -f lib/cosNotification/test/Makefile; then \ (cd lib/cosNotification/test; make TESTROOT=/home/travis/src/main-otp/release/tests release_tests) || exit $?; \ fi make[1]: Entering directory `/home/travis/src/main-otp/lib/cosNotification/test' make -w RELEASE_PATH=/home/travis/src/main-otp/release/tests release_tests_spec make[2]: Entering directory `/home/travis/src/main-otp/lib/cosNotification/test' /usr/bin/install -c -d /home/travis/src/main-otp/release/tests/cosNotification_test /usr/bin/install -c -m 644 cosNotification.spec \ cosNotification.cover notification_SUITE.erl grammar_SUITE.erl eventDB_SUITE.erl generated_SUITE.erl notify_test_impl.erl /home/travis/src/main-otp/release/tests/cosNotification_test /usr/bin/install -c -d /home/travis/src/main-otp/release/tests/cosNotification_test/idl_output /usr/bin/install -c -m 644 idl_output/oe_notify_test_server.beam idl_output/notify_test_data.beam idl_output/notify_test_computer.beam idl_output/notify_test_studies.beam idl_output/notify_test_ShortArray.beam idl_output/notify_test_uni1.beam idl_output/notify_test_uni2.beam idl_output/notify_test_X.beam idl_output/notify_test_K.beam idl_output/notify_test_SeqPushC.beam idl_output/notify_test_StrPushC.beam idl_output/notify_test_AnyPushC.beam idl_output/notify_test_SeqPullC.beam idl_output/notify_test_StrPullC.beam idl_output/notify_test_AnyPullC.beam idl_output/notify_test_SeqPushS.beam idl_output/notify_test_StrPushS.beam idl_output/notify_test_AnyPushS.beam idl_output/notify_test_SeqPullS.beam idl_output/notify_test_StrPullS.beam idl_output/notify_test_AnyPullS.beam idl_output/notify_test_funcs.beam idl_output/oe_notify_test_server.hrl idl_output/notify_test_SeqPushC.hrl idl_output/notify_test_StrPushC.hrl idl_output/notify_test_AnyPushC.hrl idl_output/notify_test_SeqPullC.hrl idl_output/notify_test_StrPullC.hrl idl_output/notify_test_AnyPullC.hrl idl_output/notify_test_SeqPushS.hrl idl_output/notify_test_StrPushS.hrl idl_output/notify_test_AnyPushS.hrl idl_output/notify_test_SeqPullS.hrl idl_output/notify_test_StrPullS.hrl idl_output/notify_test_AnyPullS.hrl idl_output/notify_test.hrl idl_output/notify_test_funcs.hrl idl_output/oe_notify_test_server.erl idl_output/notify_test_data.erl idl_output/notify_test_computer.erl idl_output/notify_test_studies.erl idl_output/notify_test_ShortArray.erl idl_output/notify_test_uni1.erl idl_output/notify_test_uni2.erl idl_output/notify_test_X.erl idl_output/notify_test_K.erl idl_output/notify_test_SeqPushC.erl idl_output/notify_test_StrPushC.erl idl_output/notify_test_AnyPushC.erl idl_output/notify_test_SeqPullC.erl idl_output/notify_test_StrPullC.erl idl_output/notify_test_AnyPullC.erl idl_output/notify_test_SeqPushS.erl idl_output/notify_test_StrPushS.erl idl_output/notify_test_AnyPushS.erl idl_output/notify_test_SeqPullS.erl idl_output/notify_test_StrPullS.erl idl_output/notify_test_AnyPullS.erl idl_output/notify_test_funcs.erl \ /home/travis/src/main-otp/release/tests/cosNotification_test/idl_output /usr/bin/install -c -m 644 notification_SUITE.beam grammar_SUITE.beam eventDB_SUITE.beam generated_SUITE.beam notify_test_impl.beam /home/travis/src/main-otp/release/tests/cosNotification_test make[2]: Leaving directory `/home/travis/src/main-otp/lib/cosNotification/test' make[1]: Leaving directory `/home/travis/src/main-otp/lib/cosNotification/test' if test -f lib/cosProperty/test/Makefile; then \ (cd lib/cosProperty/test; make TESTROOT=/home/travis/src/main-otp/release/tests release_tests) || exit $?; \ fi make[1]: Entering directory `/home/travis/src/main-otp/lib/cosProperty/test' make -w RELEASE_PATH=/home/travis/src/main-otp/release/tests release_tests_spec make[2]: Entering directory `/home/travis/src/main-otp/lib/cosProperty/test' /usr/bin/install -c -d /home/travis/src/main-otp/release/tests/cosProperty_test /usr/bin/install -c -m 644 cosProperty.spec \ cosProperty.cover property_SUITE.erl generated_SUITE.erl /home/travis/src/main-otp/release/tests/cosProperty_test /usr/bin/install -c -m 644 property_SUITE.beam generated_SUITE.beam /home/travis/src/main-otp/release/tests/cosProperty_test make[2]: Leaving directory `/home/travis/src/main-otp/lib/cosProperty/test' make[1]: Leaving directory `/home/travis/src/main-otp/lib/cosProperty/test' if test -f lib/cosTime/test/Makefile; then \ (cd lib/cosTime/test; make TESTROOT=/home/travis/src/main-otp/release/tests release_tests) || exit $?; \ fi make[1]: Entering directory `/home/travis/src/main-otp/lib/cosTime/test' make -w RELEASE_PATH=/home/travis/src/main-otp/release/tests release_tests_spec make[2]: Entering directory `/home/travis/src/main-otp/lib/cosTime/test' /usr/bin/install -c -d /home/travis/src/main-otp/release/tests/cosTime_test /usr/bin/install -c -m 644 cosTime.spec \ cosTime.cover time_SUITE.erl generated_SUITE.erl /home/travis/src/main-otp/release/tests/cosTime_test /usr/bin/install -c -m 644 time_SUITE.beam generated_SUITE.beam /home/travis/src/main-otp/release/tests/cosTime_test make[2]: Leaving directory `/home/travis/src/main-otp/lib/cosTime/test' make[1]: Leaving directory `/home/travis/src/main-otp/lib/cosTime/test' if test -f lib/cosTransactions/test/Makefile; then \ (cd lib/cosTransactions/test; make TESTROOT=/home/travis/src/main-otp/release/tests release_tests) || exit $?; \ fi make[1]: Entering directory `/home/travis/src/main-otp/lib/cosTransactions/test' make -w RELEASE_PATH=/home/travis/src/main-otp/release/tests release_tests_spec make[2]: Entering directory `/home/travis/src/main-otp/lib/cosTransactions/test' /usr/bin/install -c -d /home/travis/src/main-otp/release/tests/cosTransactions_test /usr/bin/install -c -m 644 etrap_test.idl cosTransactions.spec \ cosTransactions.cover transactions_SUITE.erl etrap_test_server_impl.erl etrap_test_lib.erl generated_SUITE.erl etrap_test_lib.hrl /home/travis/src/main-otp/release/tests/cosTransactions_test /usr/bin/install -c -m 644 transactions_SUITE.beam etrap_test_server_impl.beam etrap_test_lib.beam generated_SUITE.beam /home/travis/src/main-otp/release/tests/cosTransactions_test /usr/bin/install -c -d /home/travis/src/main-otp/release/tests/cosTransactions_test/idl_output /usr/bin/install -c -m 644 idl_output/oe_etrap_test.beam idl_output/etrap_test_server.beam idl_output/oe_etrap_test.hrl idl_output/etrap_test_server.hrl idl_output/oe_etrap_test.erl idl_output/etrap_test_server.erl \ /home/travis/src/main-otp/release/tests/cosTransactions_test/idl_output make[2]: Leaving directory `/home/travis/src/main-otp/lib/cosTransactions/test' make[1]: Leaving directory `/home/travis/src/main-otp/lib/cosTransactions/test' if test -f lib/crypto/test/Makefile; then \ (cd lib/crypto/test; make TESTROOT=/home/travis/src/main-otp/release/tests release_tests) || exit $?; \ fi make[1]: Entering directory `/home/travis/src/main-otp/lib/crypto/test' make -w RELEASE_PATH=/home/travis/src/main-otp/release/tests release_tests_spec make[2]: Entering directory `/home/travis/src/main-otp/lib/crypto/test' /home/travis/src/main-otp/make/make_emakefile +debug_info -I/home/travis/src/main-otp/lib/test_server/include -o. \ blowfish_SUITE crypto_SUITE > Emakefile /usr/bin/install -c -d /home/travis/src/main-otp/release/tests/crypto_test /usr/bin/install -c -m 644 crypto.spec crypto.cover Emakefile blowfish_SUITE.erl crypto_SUITE.erl /home/travis/src/main-otp/release/tests/crypto_test chmod -R u+w /home/travis/src/main-otp/release/tests/crypto_test make[2]: Leaving directory `/home/travis/src/main-otp/lib/crypto/test' make[1]: Leaving directory `/home/travis/src/main-otp/lib/crypto/test' if test -f lib/debugger/test/Makefile; then \ (cd lib/debugger/test; make TESTROOT=/home/travis/src/main-otp/release/tests release_tests) || exit $?; \ fi make[1]: Entering directory `/home/travis/src/main-otp/lib/debugger/test' make -w RELEASE_PATH=/home/travis/src/main-otp/release/tests release_tests_spec make[2]: Entering directory `/home/travis/src/main-otp/lib/debugger/test' /home/travis/src/main-otp/make/make_emakefile +debug_info -I/home/travis/src/main-otp/lib/test_server/include -o. andor_SUITE bs_bincomp_SUITE bs_construct_SUITE bs_match_bin_SUITE bs_match_int_SUITE bs_match_misc_SUITE bs_match_tail_SUITE bs_utf_SUITE bug_SUITE erl_eval_SUITE dbg_ui_SUITE debugger_SUITE int_SUITE int_break_SUITE int_eval_SUITE guard_SUITE exception_SUITE fun_SUITE lc_SUITE record_SUITE trycatch_SUITE test_lib cleanup \ > Emakefile /home/travis/src/main-otp/make/make_emakefile +debug_info -I/home/travis/src/main-otp/lib/test_server/include -o. '*_SUITE_make' \ >> Emakefile /usr/bin/install -c -d /home/travis/src/main-otp/release/tests/debugger_test /usr/bin/install -c -m 644 Emakefile andor_SUITE.erl bs_bincomp_SUITE.erl bs_construct_SUITE.erl bs_match_bin_SUITE.erl bs_match_int_SUITE.erl bs_match_misc_SUITE.erl bs_match_tail_SUITE.erl bs_utf_SUITE.erl bug_SUITE.erl erl_eval_SUITE.erl dbg_ui_SUITE.erl debugger_SUITE.erl int_SUITE.erl int_break_SUITE.erl int_eval_SUITE.erl guard_SUITE.erl exception_SUITE.erl fun_SUITE.erl lc_SUITE.erl record_SUITE.erl trycatch_SUITE.erl test_lib.erl cleanup.erl /home/travis/src/main-otp/release/tests/debugger_test /usr/bin/install -c -m 644 debugger.spec debugger.cover /home/travis/src/main-otp/release/tests/debugger_test chmod -R u+w /home/travis/src/main-otp/release/tests/debugger_test make[2]: Leaving directory `/home/travis/src/main-otp/lib/debugger/test' make[1]: Leaving directory `/home/travis/src/main-otp/lib/debugger/test' if test -f lib/dialyzer/test/Makefile; then \ (cd lib/dialyzer/test; make TESTROOT=/home/travis/src/main-otp/release/tests release_tests) || exit $?; \ fi make[1]: Entering directory `/home/travis/src/main-otp/lib/dialyzer/test' make -w RELEASE_PATH=/home/travis/src/main-otp/release/tests release_tests_spec make[2]: Entering directory `/home/travis/src/main-otp/lib/dialyzer/test' /usr/bin/install -c -d /home/travis/src/main-otp/release/tests/dialyzer_test chmod -f -R u+w /home/travis/src/main-otp/release/tests/dialyzer_test /usr/bin/install -c -m 644 dialyzer.spec dialyzer_test_constants.hrl dialyzer_common.erl file_utils.erl plt_SUITE.erl /home/travis/src/main-otp/release/tests/dialyzer_test cd /home/travis/src/main-otp/release/tests/dialyzer_test;\ erl -make;\ erl -noshell -run dialyzer_common create_all_suites -s erlang halt {"init terminating in do_boot",{undef,[{make,all,[]},{init,start_it,1},{init,start_em,1}]}} Crash dump was written to: erl_crash.dump init terminating in do_boot () {"init terminating in do_boot",{undef,[{dialyzer_common,create_all_suites,[]},{init,start_it,1},{init,start_em,1}]}} Crash dump was written to: erl_crash.dump init terminating in do_boot () make[2]: *** [release_tests_spec] Error 1 make[2]: Leaving directory `/home/travis/src/main-otp/lib/dialyzer/test' make[1]: *** [release_tests] Error 2 make[1]: Leaving directory `/home/travis/src/main-otp/lib/dialyzer/test' make: *** [lib/dialyzer/test] Error 2 travis@REDACTED:~/src/main-otp$ -- *Travis Jensen* *** *Read the Software Maven @ http://softwaremaven.innerbrane.com/ Read my LinkedIn profile @ http://www.linkedin.com/in/travisjensen Read my Twitter mumblings @ http://twitter.com/SoftwareMaven Send me email @ travis.jensen@REDACTED **What kind of guy calls himself the Software Maven???** -------------- next part -------------- An HTML attachment was scrubbed... URL: From overminddl1@REDACTED Fri May 6 04:28:08 2011 From: overminddl1@REDACTED (OvermindDL1) Date: Thu, 5 May 2011 20:28:08 -0600 Subject: [erlang-questions] Binding variables from binaries in function headers In-Reply-To: References: <4D76EA62.1080608@m5net.com> Message-ID: On Wed, Mar 9, 2011 at 3:56 PM, OvermindDL1 wrote: > On Wed, Mar 9, 2011 at 3:48 PM, OvermindDL1 wrote: >> On Tue, Mar 8, 2011 at 9:26 PM, Wes James wrote: >>> On Tue, Mar 8, 2011 at 7:48 PM, Bernard Duggan wrote: >>>> So I've just run into an interesting little bit of behaviour that doesn't >>>> seem quite right. ?In the following code: >>>> ----------------------------------------- >>>> -module(casetest). >>>> >>>> -export([test/0]). >>>> >>>> test() -> >>>> ? ?match(<<1, 2, 3, 4, 5, 6, 7, 8>>). >>>> >>>> match(<>) -> >>>> ? ?case A of >>>> ? ? ? ?B -> wrong; >>>> ? ? ? ?_ -> ok >>>> ? ?end. >>> >>> >>> >>> I just ran it in the debugger: >>> >>> c(casetest,[debug_info]). >>> im(). >>> ii(casetest). >>> iaa([init]). >>> >>> and it follows the _ -> ok branch and returns ok. >>> >>> Entering the function (the debugger stops at "case A of" ) the vars are: >>> >>> A is <<1>> >>> B is 2 >>> _C is <<3,4> >>> _Rest is <<5,6,7,8>> >> >> I confirm the above tests, and in fact if I change the module to this: >> """ >> module(casetest). >> >> -export([test/0]). >> >> test() -> >> ? match(<<1, 2, 3, 4, 5, 6, 7, 8>>). >> >> match(<>) -> >> ? io:format("~p~n", [{A,B,_C,_Rest}]), >> ? case A of >> ? ? ? B -> wrong; >> ? ? ? _ -> ok >> ? end. >> """ >> >> Then the erl shell does this: >> Erlang R14B01 (erts-5.8.2) [source] [64-bit] [smp:6:6] [rq:6] >> [async-threads:0] [hipe] [kernel-poll:false] >> >> Eshell V5.8.2 ?(abort with ^G) >> 1> c(casetest). >> ./casetest.erl:12: Warning: this clause cannot match because a >> previous clause at line 11 always matches >> {ok,casetest} >> 2> casetest:test(). >> {<<1>>,2,<<3,4>>,<<5,6,7,8>>} >> wrong >> 3> >> >> >> What is going on here? ?I use binaries heavily in my apps and I would >> like to be assured that this bug will not sneak in. > > > I just confirmed it in R13B03 as well: > > Erlang R13B03 (erts-5.7.4) [source] [64-bit] [smp:6:6] [rq:6] > [async-threads:0] [hipe] [kernel-poll:false] > > Eshell V5.7.4 ?(abort with ^G) > 1> c(casetest). > ./casetest.erl:12: Warning: this clause cannot match because a > previous clause at line 11 always matches > {ok,casetest} > 2> casetest:test(). > {<<1>>,2,<<3,4>>,<<5,6,7,8>>} > wrong > 3> Not to beat a dead horse, but this still worries me, any thoughts? Even if not fixable in the old versions, I would at least like to know the reason 'why' it breaks so as to help prevent it in the future... From chandrashekhar.mullaparthi@REDACTED Fri May 6 05:51:25 2011 From: chandrashekhar.mullaparthi@REDACTED (Chandru) Date: Fri, 6 May 2011 04:51:25 +0100 Subject: [erlang-questions] mochiweb https/ssl In-Reply-To: <1304632965.1894.13.camel@sasa-laptop> References: <1304632965.1894.13.camel@sasa-laptop> Message-ID: Hi, To rule out any issues with the implementation of ssl, I would suggest you use stunnel (http://www.stunnel.org) to firstly do the SSL handling for you. If your https tests work properly with that, then we know it is an issue with the OTP implementation of SSL. If you still have the same problems, it could be a problem with your setup. cheers Chandru On 5 May 2011 23:02, sasa wrote: > Hello, > > First of all, I apologize if this question occurs twice. I have tried > submitting it couple of hours ago via google groups, but it didn't show up, > so I'm trying via e-mail now. > > I am trying to develop https comet (long polling) server using mochiweb. I > have already written one such http server which is in production for couple > of months and serves no more than 1000 concurrent users, sending broadcast > message to all concurrent users at an average rate of 0.3 broadcast/sec > > When I added ssl support, it essentially works when smaller number of users > (about 100-200) are connected. With larger number, it stops responding > correctly i.e. some connection attempts are refused, requests time out etc.Only ssl/https part seems to be affected by this behavior. > > To better test this, I developed small test mochiweb app which works as > follows: > 1. Spawn and register singleton broadcast process > 2. For each request, the erlang process sends its pid to the broadcast > process. Then it waits for the message from the broadcast process > 3. Every 5 seconds broadcast process notifies all registered https response > processes from 2, then it clears its list of registered processes > 4. When process from 2 receives notification, it responds and finishes. > > In this test implementation, the response is hardcoded short string. For > the sake of brevity, I didn't include the test app code, but if necessary I > can do so. > > > I then deployed this test app to the server, and set up two client > machines to load test the server. The load testing code is also written in > erlang, and is using ibrowse for making https requests, since I had some > problems with httpc. The test client basically adheres to the protocol > described above. It spawns request processes, with each process making the > requests in an infinite loop. I gather success/failure stats in a s > ingleton erlang process and print them out in regular intervals. > > As in the production system, with http, the test server performs > correctly. With https, when number of concurrent requests reaches some > treshold (about 1000), many requests are not served. > > On the client machine, I occasionally receive following errors: > =ERROR REPORT==== > ** State machine <0.17592.0> terminating > > ** Reason for termination = > ** {badarg,[{erlang,byte_size,[undefined]}, > {ssl_tls1,split_secret,1}, > {ssl_tls1,prf,4}, > {ssl_handshake,master_secret,4}, > {ssl_connection,handle_resumed_session,2}, > {ssl_connection,next_state,3}, > {gen_fsm,handle_msg,7}, > {proc_lib,init_p_do_apply,3}]} > > > While on the server I occasionally notice following errors: > =SUPERVISOR REPORT==== 5-May-2011::11:06:33 === > Supervisor: {local,ssl_connection_sup} > Context: child_terminated > Reason: {{badmatch,{resumed,undefined}}, > [{ssl_handshake,hello,4}, > {ssl_connection,hello,2}, > {ssl_connection,next_state,3}, > {gen_fsm,handle_msg,7}, > {proc_lib,init_p_do_apply,3}]} > Offender: [{pid,<0.7044.2>}, > {name,undefined}, > {mfargs,{ssl_connection,start_link,undefined}}, > {restart_type,temporary}, > {shutdown,4000}, > {child_type,worker}] > > > I have tried to tweak some OS parameters, as well as erlang parameters, but > without success. After three days of experimenting, I am out of ideas and > need some help or pointers. > > I am using Erlang R14B02 on 64 bit Ubuntu 10.04, all the machines are on > the EC2 cloud. > > Following are sysctl.conf settings (I tried some more combinations without > success): > net.core.rmem_max = 16777216 > net.core.wmem_max = 16777216 > net.ipv4.tcp_rmem = 4096 87380 16777216 > net.ipv4.tcp_wmem = 4096 65536 16777216 > net.ipv4.tcp_syncookies = 1 > > net.ipv4.tcp_mem = 50576 64768 98152 > net.core.netdev_max_backlog = 2500 > net.ipv4.netfilter.ip_conntrack_max = 1048576 > > net.ipv4.ip_local_port_range = 1024 65535 > > net.ipv4.tcp_fin_timeout = 10 > > > > Following is ulimit -a output: > core file size (blocks, -c) 0 > data seg size (kbytes, -d) unlimited > scheduling priority (-e) 20 > file size (blocks, -f) unlimited > pending signals (-i) 16382 > max locked memory (kbytes, -l) 64 > max memory size (kbytes, -m) unlimited > open files (-n) 32000 > pipe size (512 bytes, -p) 8 > POSIX message queues (bytes, -q) 819200 > real-time priority (-r) 0 > stack size (kbytes, -s) 8192 > cpu time (seconds, -t) unlimited > max user processes (-u) unlimited > virtual memory (kbytes, -v) unlimited > file locks (-x) unlimited > > > > These are mochiweb parameters: > [ > {port, 9999}, > {name, https_test}, > {ssl, true}, > {ssl_opts, [ > {cacertfile, "keys/cacert.pem"}, > {certfile, "keys/cert.pem"}, > {keyfile, "keys/cert.key"}, > {depth, 0} > ]} > ] > > > To use it on a 443 port, I have set up iptables port forwarding > iptables -t nat -I PREROUTING --source 0/0 --destination 0/0 -p tcp --dport > 443 -j REDIRECT --to-ports 9999 > > > These are erl parameters: > erl -P 268435456 -env ERL_MAX_PORTS 100000 > > > > If anybody has any idea, I would be most grateful. > > > Best regards, > Sasa > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Fri May 6 07:34:22 2011 From: ok@REDACTED (Richard O'Keefe) Date: Fri, 6 May 2011 17:34:22 +1200 Subject: [erlang-questions] byte() vs. char() use in documentation In-Reply-To: References: <20110502091415.GA6512@erix.ericsson.se> <20110503094549.GA10981@erix.ericsson.se> <201105040533.58985.als@iinet.net.au> <20110504075734.GA16456@erix.ericsson.se> Message-ID: <294BF31C-A04F-49C1-8CCB-E168D5AFAE5B@cs.otago.ac.nz> On 5/05/2011, at 7:16 PM, Lionel Cons wrote: > AFAIK, the confusion comes from two different uses of the term "character". > > The "individual character" is at the heart of Unicode. Each individual > character maps to a unique code point. For instance, a lowercase alpha is > the character named "GREEK SMALL LETTER ALPHA" and maps to code point > U+03B1. The Unicode code points are between 0 and 0x10FFFF. > > The "logical character" is what human beings usually have in mind. In the > real world, a text is a sequence of logical characters. An example of such > a character is the lowercase letter "e" with an acute accent. One major problem here is that there is no such thing as a universally agreed "logical character". In the context of my sister-in-law's name (Ch?ri), "?" is a single accented letter. In the context of a word in "belov?d", perhaps in an English poem, "?" is two conceptually *separate* characters, a letter "e" and a prosodic marker. Now "?" can be encoded in Unicode either as a single code point or as two code points, one of them a floating diacritical, so we actually have four combinations: one human character, one code point one human character, two code points two human characters, one code point two human characters, two code points. This is why I am totally unimpressed by suggestions that we represent "characters" as binaries containing encoded sequences of code points; without a fair chunk of natural language processing, not to mention AI, WE DON'T KNOW WHICH SEQUENCES OF CODE POINTS COUNT AS SINGLE HUMAN CHARACTERS. That is why I say that everyday Unicode interfaces should be in terms of strings and *only* strings. > > To come back to the point, we have to define what we mean with the Erlang > char() type: > - if it's an individual character then it can naturally be represented as > a single integer for its code point > - if it's a logical character then it has to be a list of integers Since we cannot know what a logical character is, and since we need *some* representation of Unicode code points, I recommend that char()=code point. > > In any case, the language must provide specific functions to work on strings > and characters. For instance, a logical character comparison must take into > account the Unicode equivalence. What do you mean "THE" equivalence?\ From masklinn@REDACTED Fri May 6 08:49:11 2011 From: masklinn@REDACTED (Masklinn) Date: Fri, 6 May 2011 08:49:11 +0200 Subject: [erlang-questions] byte() vs. char() use in documentation In-Reply-To: <294BF31C-A04F-49C1-8CCB-E168D5AFAE5B@cs.otago.ac.nz> References: <20110502091415.GA6512@erix.ericsson.se> <20110503094549.GA10981@erix.ericsson.se> <201105040533.58985.als@iinet.net.au> <20110504075734.GA16456@erix.ericsson.se> <294BF31C-A04F-49C1-8CCB-E168D5AFAE5B@cs.otago.ac.nz> Message-ID: <60C82374-90CF-4200-9F87-1B662173A4B1@masklinn.net> On 2011-05-06, at 07:34 , Richard O'Keefe wrote: >> To come back to the point, we have to define what we mean with the Erlang >> char() type: >> - if it's an individual character then it can naturally be represented as >> a single integer for its code point >> - if it's a logical character then it has to be a list of integers > Since we cannot know what a logical character is, and since we need *some* > representation of Unicode code points, I recommend that char()=code point. Why pick code points rather than grapheme cluster? >> In any case, the language must provide specific functions to work on strings >> and characters. For instance, a logical character comparison must take into >> account the Unicode equivalence. > What do you mean "THE" equivalence?\ I would guess he means what he linked: unicode equivalence (as per unicode), likely compatible (in order to equate "?" with "ffi" for instance) From sedrik@REDACTED Fri May 6 08:56:55 2011 From: sedrik@REDACTED (Fredrik Andersson) Date: Fri, 6 May 2011 08:56:55 +0200 Subject: [erlang-questions] Building erlang tests In-Reply-To: References: Message-ID: I havent trid the latest pu branch but when I generate test I use ./otp_build tests [-a] so you could give that a go. Does it work if you try to do it on the R14B02 release? On Fri, May 6, 2011 at 12:43 AM, Travis Jensen wrote: > I'm trying to get the Erlang unit tests running under Linux (pu branch). > I've gone through a full compile and then did "make release_tests". I'm > getting the following output. Is there anywhere with instructions about how > to really get the unit tests working? The wiki on github isn't cutting it > for me. > > Thanks. > > tj > > travis@REDACTED:~/src/main-otp$ make release_tests > if test -f lib/test_server/Makefile; then \ > (cd lib/test_server; make TESTROOT=/home/travis/src/main-otp/release/tests > release_tests) || exit $?; \ > fi > make[1]: Entering directory `/home/travis/src/main-otp/lib/test_server' > === Entering application test_server > make[2]: Entering directory `/home/travis/src/main-otp/lib/test_server/src' > make -w RELEASE_PATH=/home/travis/src/main-otp/release/tests > release_tests_spec > make[3]: Entering directory `/home/travis/src/main-otp/lib/test_server/src' > /usr/bin/install -c -d /home/travis/src/main-otp/release/tests/test_server > /usr/bin/install -c -m 644 test_server_ctrl.erl test_server_node.erl > test_server.erl test_server_sup.erl test_server_line.erl test_server_h.erl > erl2html2.erl vxworks_client.erl ts.erl ts_run.erl ts_reports.erl ts_lib.erl > ts_make.erl ts_erl_config.erl ts_autoconf_win32.erl ts_autoconf_vxworks.erl > ts_install.erl ts_install_cth.erl \ > ../include/test_server.hrl ../include/test_server_line.hrl > test_server_internal.hrl ts.hrl \ > ../ebin/ts.beam ../ebin/ts_run.beam ../ebin/ts_reports.beam > ../ebin/ts_lib.beam ../ebin/ts_make.beam ../ebin/ts_erl_config.beam > ../ebin/ts_autoconf_win32.beam ../ebin/ts_autoconf_vxworks.beam > ../ebin/ts_install.beam ../ebin/ts_install_cth.beam \ > configure.in conf_vars.in cross.cover ts.config ts.unix.config > ts.win32.config \ > /home/travis/src/main-otp/release/tests/test_server > /usr/bin/install -c configure config.sub config.guess install-sh > /home/travis/src/main-otp/release/tests/test_server > make[3]: Leaving directory `/home/travis/src/main-otp/lib/test_server/src' > make[2]: Leaving directory `/home/travis/src/main-otp/lib/test_server/src' > make[2]: Entering directory > `/home/travis/src/main-otp/lib/test_server/doc/src' > make -w RELEASE_PATH=/home/travis/src/main-otp/release/tests > release_tests_spec > make[3]: Entering directory > `/home/travis/src/main-otp/lib/test_server/doc/src' > make[3]: Nothing to be done for `release_tests_spec'. > make[3]: Leaving directory > `/home/travis/src/main-otp/lib/test_server/doc/src' > make[2]: Leaving directory > `/home/travis/src/main-otp/lib/test_server/doc/src' > === Leaving application test_server > make[1]: Leaving directory `/home/travis/src/main-otp/lib/test_server' > if test -f lib/asn1/test/Makefile; then \ > (cd lib/asn1/test; make TESTROOT=/home/travis/src/main-otp/release/tests > release_tests) || exit $?; \ > fi > make[1]: Entering directory `/home/travis/src/main-otp/lib/asn1/test' > make -w RELEASE_PATH=/home/travis/src/main-otp/release/tests > release_tests_spec > make[2]: Entering directory `/home/travis/src/main-otp/lib/asn1/test' > /usr/bin/install -c -d /home/travis/src/main-otp/release/tests/asn1_test > /usr/bin/install -c -d > /home/travis/src/main-otp/release/tests/asn1_test/asn1_SUITE_data > /usr/bin/install -c -d > /home/travis/src/main-otp/release/tests/asn1_test/asn1_bin_SUITE_data > /usr/bin/install -c -d > /home/travis/src/main-otp/release/tests/asn1_test/asn1_bin_v2_SUITE_data > /usr/bin/install -c -m 644 h323test.erl choice_extension.erl > ber_decode_error.erl testExternal.erl testPrim.erl testPrimStrings.erl > testCompactBitString.erl testPrimExternal.erl testChoPrim.erl > testChoExtension.erl testChoExternal.erl testChoOptional.erl > testChoOptionalImplicitTag.erl testChoRecursive.erl testChoTypeRefCho.erl > testChoTypeRefPrim.erl testChoTypeRefSeq.erl testChoTypeRefSet.erl > testConstraints.erl testDef.erl testOpt.erl testSeqDefault.erl > testSeqExtension.erl testSeqExternal.erl testSeqOptional.erl testSeq2738.erl > testSeqPrim.erl testSeqTag.erl testSeqTypeRefCho.erl testSeqTypeRefPrim.erl > testSeqTypeRefSeq.erl testSeqTypeRefSet.erl testSeqIndefinite.erl > testSeqOf.erl testSeqOfIndefinite.erl testSeqOfCho.erl testSeqOfExternal.erl > testSeqOfTag.erl testSetDefault.erl testSetExtension.erl testSetExternal.erl > testSetOptional.erl testSetPrim.erl testSetTag.erl testSetTypeRefCho.erl > testSetTypeRefPrim.erl testSetTypeRefSeq.erl testSetTypeRefSet.erl > testSetIndefinite.erl testChoiceIndefinite.erl testSetOf.erl > testSetOfCho.erl testSetOfExternal.erl testSetOfTag.erl testEnumExt.erl > testInfObjectClass.erl testInfObj.erl testParameterizedInfObj.erl > testMergeCompile.erl testDeepTConstr.erl testTimer.erl testRANAP.erl > testMegaco.erl testMvrasn6.erl testSeqSetDefaultVal.erl testParamBasic.erl > testContextSwitchingTypes.erl testTypeValueNotation.erl > testOpenTypeImplicitTag.erl testROSE.erl testINSTANCE_OF.erl > test_partial_incomplete_decode.erl testDER.erl test_selective_decode.erl > test_special_decode_performance.erl testTCAP.erl testSSLspecs.erl > test_driver_load.erl testSelectionTypes.erl test_undecoded_rest.erl > test_inline.erl testTcapsystem.erl testNBAPsystem.erl test_bad_values.erl > test_compile_options.erl testDoubleEllipses.erl test_modified_x420.erl > testX420.erl test_x691.erl asn1_test_lib.erl asn1_app_test.erl > asn1_appup_test.erl asn1_wrapper.erl asn1_SUITE.erl asn1_bin_SUITE.erl > asn1_bin_v2_SUITE.erl External.hrl > /home/travis/src/main-otp/release/tests/asn1_test > /usr/bin/install -c -m 644 asn1.spec asn1.cover > /home/travis/src/main-otp/release/tests/asn1_test > chmod -R u+w /home/travis/src/main-otp/release/tests/asn1_test > cd asn1_SUITE_data; tar cfh > /home/travis/src/main-otp/release/tests/asn1_test/asn1_SUITE_data.tar * > cd /home/travis/src/main-otp/release/tests/asn1_test/asn1_SUITE_data; tar > xf /home/travis/src/main-otp/release/tests/asn1_test/asn1_SUITE_data.tar > cd /home/travis/src/main-otp/release/tests/asn1_test/asn1_bin_SUITE_data; > tar xf /home/travis/src/main-otp/release/tests/asn1_test/asn1_SUITE_data.tar > cd > /home/travis/src/main-otp/release/tests/asn1_test/asn1_bin_v2_SUITE_data; > tar xf /home/travis/src/main-otp/release/tests/asn1_test/asn1_SUITE_data.tar > rm /home/travis/src/main-otp/release/tests/asn1_test/asn1_SUITE_data.tar > make[2]: Leaving directory `/home/travis/src/main-otp/lib/asn1/test' > make[1]: Leaving directory `/home/travis/src/main-otp/lib/asn1/test' > if test -f lib/common_test/test/Makefile; then \ > (cd lib/common_test/test; make > TESTROOT=/home/travis/src/main-otp/release/tests release_tests) || exit $?; > \ > fi > make[1]: Entering directory > `/home/travis/src/main-otp/lib/common_test/test' > make -w RELEASE_PATH=/home/travis/src/main-otp/release/tests > release_tests_spec > make[2]: Entering directory > `/home/travis/src/main-otp/lib/common_test/test' > /usr/bin/install -c -d > /home/travis/src/main-otp/release/tests/common_test_test > /usr/bin/install -c -m 644 ct_test_support.erl ct_test_support_eh.erl > ct_userconfig_callback.erl ct_smoke_test_SUITE.erl > ct_event_handler_SUITE.erl ct_groups_test_1_SUITE.erl > ct_groups_test_2_SUITE.erl ct_sequence_1_SUITE.erl ct_repeat_1_SUITE.erl > ct_testspec_1_SUITE.erl ct_skip_SUITE.erl ct_error_SUITE.erl > ct_test_server_if_1_SUITE.erl ct_config_SUITE.erl ct_master_SUITE.erl > ct_misc_1_SUITE.erl ct_hooks_SUITE.erl > /home/travis/src/main-otp/release/tests/common_test_test > /usr/bin/install -c -m 644 common_test.spec > /home/travis/src/main-otp/release/tests/common_test_test > chmod -R u+w /home/travis/src/main-otp/release/tests/common_test_test > make[2]: Leaving directory `/home/travis/src/main-otp/lib/common_test/test' > make[1]: Leaving directory `/home/travis/src/main-otp/lib/common_test/test' > if test -f lib/compiler/test/Makefile; then \ > (cd lib/compiler/test; make > TESTROOT=/home/travis/src/main-otp/release/tests release_tests) || exit $?; > \ > fi > make[1]: Entering directory `/home/travis/src/main-otp/lib/compiler/test' > make -w RELEASE_PATH=/home/travis/src/main-otp/release/tests > release_tests_spec > make[2]: Entering directory `/home/travis/src/main-otp/lib/compiler/test' > /home/travis/src/main-otp/make/make_emakefile +debug_info > -I/home/travis/src/main-otp/lib/test_server/include +clint -o. andor_SUITE > apply_SUITE beam_validator_SUITE bs_bincomp_SUITE bs_bit_binaries_SUITE > bs_construct_SUITE bs_match_SUITE bs_utf_SUITE core_fold_SUITE compile_SUITE > compilation_SUITE core_SUITE error_SUITE float_SUITE fun_SUITE guard_SUITE > inline_SUITE lc_SUITE match_SUITE misc_SUITE num_bif_SUITE pmod_SUITE > parteval_SUITE receive_SUITE record_SUITE trycatch_SUITE warnings_SUITE > test_lib \ > > Emakefile > /home/travis/src/main-otp/make/make_emakefile +no_copt +no_postopt > +debug_info -I/home/travis/src/main-otp/lib/test_server/include +clint \ > -o. andor_no_opt_SUITE apply_no_opt_SUITE bs_construct_no_opt_SUITE > bs_match_no_opt_SUITE bs_utf_no_opt_SUITE core_fold_no_opt_SUITE > float_no_opt_SUITE fun_no_opt_SUITE guard_no_opt_SUITE lc_no_opt_SUITE > match_no_opt_SUITE misc_no_opt_SUITE num_bif_no_opt_SUITE > receive_no_opt_SUITE record_no_opt_SUITE trycatch_no_opt_SUITE >> Emakefile > /home/travis/src/main-otp/make/make_emakefile +no_copt +debug_info > -I/home/travis/src/main-otp/lib/test_server/include +clint \ > -o. andor_post_opt_SUITE apply_post_opt_SUITE bs_construct_post_opt_SUITE > bs_match_post_opt_SUITE bs_utf_post_opt_SUITE core_fold_post_opt_SUITE > float_post_opt_SUITE fun_post_opt_SUITE guard_post_opt_SUITE > lc_post_opt_SUITE match_post_opt_SUITE misc_post_opt_SUITE > num_bif_post_opt_SUITE receive_post_opt_SUITE record_post_opt_SUITE > trycatch_post_opt_SUITE >> Emakefile > /home/travis/src/main-otp/make/make_emakefile +inline +debug_info > -I/home/travis/src/main-otp/lib/test_server/include +clint \ > -o. andor_inline_SUITE apply_inline_SUITE bs_bincomp_inline_SUITE > bs_bit_binaries_inline_SUITE bs_construct_inline_SUITE bs_match_inline_SUITE > bs_utf_inline_SUITE core_fold_inline_SUITE float_inline_SUITE > fun_inline_SUITE guard_inline_SUITE lc_inline_SUITE match_inline_SUITE > misc_inline_SUITE num_bif_inline_SUITE receive_inline_SUITE > record_inline_SUITE >> Emakefile > /usr/bin/install -c -d > /home/travis/src/main-otp/release/tests/compiler_test > /usr/bin/install -c -m 644 compiler.spec compiler.cover \ > Emakefile andor_SUITE.erl apply_SUITE.erl beam_validator_SUITE.erl > bs_bincomp_SUITE.erl bs_bit_binaries_SUITE.erl bs_construct_SUITE.erl > bs_match_SUITE.erl bs_utf_SUITE.erl core_fold_SUITE.erl compile_SUITE.erl > compilation_SUITE.erl core_SUITE.erl error_SUITE.erl float_SUITE.erl > fun_SUITE.erl guard_SUITE.erl inline_SUITE.erl lc_SUITE.erl match_SUITE.erl > misc_SUITE.erl num_bif_SUITE.erl pmod_SUITE.erl parteval_SUITE.erl > receive_SUITE.erl record_SUITE.erl trycatch_SUITE.erl warnings_SUITE.erl > test_lib.erl bs_shadowed_size_var.core nested_call_in_case.core > /home/travis/src/main-otp/release/tests/compiler_test > /usr/bin/install -c -m 644 andor_no_opt_SUITE.erl apply_no_opt_SUITE.erl > bs_construct_no_opt_SUITE.erl bs_match_no_opt_SUITE.erl > bs_utf_no_opt_SUITE.erl core_fold_no_opt_SUITE.erl float_no_opt_SUITE.erl > fun_no_opt_SUITE.erl guard_no_opt_SUITE.erl lc_no_opt_SUITE.erl > match_no_opt_SUITE.erl misc_no_opt_SUITE.erl num_bif_no_opt_SUITE.erl > receive_no_opt_SUITE.erl record_no_opt_SUITE.erl trycatch_no_opt_SUITE.erl > andor_post_opt_SUITE.erl apply_post_opt_SUITE.erl > bs_construct_post_opt_SUITE.erl bs_match_post_opt_SUITE.erl > bs_utf_post_opt_SUITE.erl core_fold_post_opt_SUITE.erl > float_post_opt_SUITE.erl fun_post_opt_SUITE.erl guard_post_opt_SUITE.erl > lc_post_opt_SUITE.erl match_post_opt_SUITE.erl misc_post_opt_SUITE.erl > num_bif_post_opt_SUITE.erl receive_post_opt_SUITE.erl > record_post_opt_SUITE.erl trycatch_post_opt_SUITE.erl \ > andor_inline_SUITE.erl apply_inline_SUITE.erl bs_bincomp_inline_SUITE.erl > bs_bit_binaries_inline_SUITE.erl bs_construct_inline_SUITE.erl > bs_match_inline_SUITE.erl bs_utf_inline_SUITE.erl core_fold_inline_SUITE.erl > float_inline_SUITE.erl fun_inline_SUITE.erl guard_inline_SUITE.erl > lc_inline_SUITE.erl match_inline_SUITE.erl misc_inline_SUITE.erl > num_bif_inline_SUITE.erl receive_inline_SUITE.erl record_inline_SUITE.erl > /home/travis/src/main-otp/release/tests/compiler_test > chmod -R u+w /home/travis/src/main-otp/release/tests/compiler_test > make[2]: Leaving directory `/home/travis/src/main-otp/lib/compiler/test' > make[1]: Leaving directory `/home/travis/src/main-otp/lib/compiler/test' > if test -f lib/cosEventDomain/test/Makefile; then \ > (cd lib/cosEventDomain/test; make > TESTROOT=/home/travis/src/main-otp/release/tests release_tests) || exit $?; > \ > fi > make[1]: Entering directory > `/home/travis/src/main-otp/lib/cosEventDomain/test' > make -w RELEASE_PATH=/home/travis/src/main-otp/release/tests > release_tests_spec > make[2]: Entering directory > `/home/travis/src/main-otp/lib/cosEventDomain/test' > /usr/bin/install -c -d > /home/travis/src/main-otp/release/tests/cosEventDomain_test > /usr/bin/install -c -m 644 cosEventDomain.spec \ > cosEventDomain.cover event_domain_SUITE.erl generated_SUITE.erl > /home/travis/src/main-otp/release/tests/cosEventDomain_test > /usr/bin/install -c -m 644 event_domain_SUITE.beam generated_SUITE.beam > /home/travis/src/main-otp/release/tests/cosEventDomain_test > make[2]: Leaving directory > `/home/travis/src/main-otp/lib/cosEventDomain/test' > make[1]: Leaving directory > `/home/travis/src/main-otp/lib/cosEventDomain/test' > if test -f lib/cosEvent/test/Makefile; then \ > (cd lib/cosEvent/test; make > TESTROOT=/home/travis/src/main-otp/release/tests release_tests) || exit $?; > \ > fi > make[1]: Entering directory `/home/travis/src/main-otp/lib/cosEvent/test' > make -w RELEASE_PATH=/home/travis/src/main-otp/release/tests > release_tests_spec > make[2]: Entering directory `/home/travis/src/main-otp/lib/cosEvent/test' > /usr/bin/install -c -d > /home/travis/src/main-otp/release/tests/cosEvent_test > /usr/bin/install -c -m 644 event_test_server.idl cosEvent.spec \ > cosEvent.cover event_test_PushC_impl.erl event_test_PullC_impl.erl > event_test_PushS_impl.erl event_test_PullS_impl.erl event_channel_SUITE.erl > generated_SUITE.erl /home/travis/src/main-otp/release/tests/cosEvent_test > /usr/bin/install -c -m 644 event_test_PushC_impl.beam > event_test_PullC_impl.beam event_test_PushS_impl.beam > event_test_PullS_impl.beam event_channel_SUITE.beam generated_SUITE.beam > /home/travis/src/main-otp/release/tests/cosEvent_test > /usr/bin/install -c -d > /home/travis/src/main-otp/release/tests/cosEvent_test/idl_output > /usr/bin/install -c -m 644 idl_output/event_test_PullC.beam > idl_output/event_test_PushS.beam idl_output/event_test_PullS.beam > idl_output/oe_event_test_server.beam idl_output/event_test_PushC.beam > idl_output/event_test.hrl idl_output/event_test_PushC.hrl > idl_output/event_test_PullC.hrl idl_output/event_test_PushS.hrl > idl_output/event_test_PullS.hrl idl_output/oe_event_test_server.hrl > idl_output/event_test_PullC.erl idl_output/event_test_PushS.erl > idl_output/event_test_PullS.erl idl_output/oe_event_test_server.erl > idl_output/event_test_PushC.erl \ > /home/travis/src/main-otp/release/tests/cosEvent_test/idl_output > make[2]: Leaving directory `/home/travis/src/main-otp/lib/cosEvent/test' > make[1]: Leaving directory `/home/travis/src/main-otp/lib/cosEvent/test' > if test -f lib/cosFileTransfer/test/Makefile; then \ > (cd lib/cosFileTransfer/test; make > TESTROOT=/home/travis/src/main-otp/release/tests release_tests) || exit $?; > \ > fi > make[1]: Entering directory > `/home/travis/src/main-otp/lib/cosFileTransfer/test' > make -w RELEASE_PATH=/home/travis/src/main-otp/release/tests > release_tests_spec > make[2]: Entering directory > `/home/travis/src/main-otp/lib/cosFileTransfer/test' > /usr/bin/install -c -d > /home/travis/src/main-otp/release/tests/cosFileTransfer_test > /usr/bin/install -c -m 644 cosFileTransfer.spec \ > cosFileTransfer.cover fileTransfer_SUITE.erl > /home/travis/src/main-otp/release/tests/cosFileTransfer_test > /usr/bin/install -c -m 644 fileTransfer_SUITE.beam > /home/travis/src/main-otp/release/tests/cosFileTransfer_test > chmod -R u+w /home/travis/src/main-otp/release/tests/cosFileTransfer_test > make[2]: Leaving directory > `/home/travis/src/main-otp/lib/cosFileTransfer/test' > make[1]: Leaving directory > `/home/travis/src/main-otp/lib/cosFileTransfer/test' > if test -f lib/cosNotification/test/Makefile; then \ > (cd lib/cosNotification/test; make > TESTROOT=/home/travis/src/main-otp/release/tests release_tests) || exit $?; > \ > fi > make[1]: Entering directory > `/home/travis/src/main-otp/lib/cosNotification/test' > make -w RELEASE_PATH=/home/travis/src/main-otp/release/tests > release_tests_spec > make[2]: Entering directory > `/home/travis/src/main-otp/lib/cosNotification/test' > /usr/bin/install -c -d > /home/travis/src/main-otp/release/tests/cosNotification_test > /usr/bin/install -c -m 644 cosNotification.spec \ > cosNotification.cover notification_SUITE.erl grammar_SUITE.erl > eventDB_SUITE.erl generated_SUITE.erl notify_test_impl.erl > /home/travis/src/main-otp/release/tests/cosNotification_test > /usr/bin/install -c -d > /home/travis/src/main-otp/release/tests/cosNotification_test/idl_output > /usr/bin/install -c -m 644 idl_output/oe_notify_test_server.beam > idl_output/notify_test_data.beam idl_output/notify_test_computer.beam > idl_output/notify_test_studies.beam idl_output/notify_test_ShortArray.beam > idl_output/notify_test_uni1.beam idl_output/notify_test_uni2.beam > idl_output/notify_test_X.beam idl_output/notify_test_K.beam > idl_output/notify_test_SeqPushC.beam idl_output/notify_test_StrPushC.beam > idl_output/notify_test_AnyPushC.beam idl_output/notify_test_SeqPullC.beam > idl_output/notify_test_StrPullC.beam idl_output/notify_test_AnyPullC.beam > idl_output/notify_test_SeqPushS.beam idl_output/notify_test_StrPushS.beam > idl_output/notify_test_AnyPushS.beam idl_output/notify_test_SeqPullS.beam > idl_output/notify_test_StrPullS.beam idl_output/notify_test_AnyPullS.beam > idl_output/notify_test_funcs.beam idl_output/oe_notify_test_server.hrl > idl_output/notify_test_SeqPushC.hrl idl_output/notify_test_StrPushC.hrl > idl_output/notify_test_AnyPushC.hrl idl_output/notify_test_SeqPullC.hrl > idl_output/notify_test_StrPullC.hrl idl_output/notify_test_AnyPullC.hrl > idl_output/notify_test_SeqPushS.hrl idl_output/notify_test_StrPushS.hrl > idl_output/notify_test_AnyPushS.hrl idl_output/notify_test_SeqPullS.hrl > idl_output/notify_test_StrPullS.hrl idl_output/notify_test_AnyPullS.hrl > idl_output/notify_test.hrl idl_output/notify_test_funcs.hrl > idl_output/oe_notify_test_server.erl idl_output/notify_test_data.erl > idl_output/notify_test_computer.erl idl_output/notify_test_studies.erl > idl_output/notify_test_ShortArray.erl idl_output/notify_test_uni1.erl > idl_output/notify_test_uni2.erl idl_output/notify_test_X.erl > idl_output/notify_test_K.erl idl_output/notify_test_SeqPushC.erl > idl_output/notify_test_StrPushC.erl idl_output/notify_test_AnyPushC.erl > idl_output/notify_test_SeqPullC.erl idl_output/notify_test_StrPullC.erl > idl_output/notify_test_AnyPullC.erl idl_output/notify_test_SeqPushS.erl > idl_output/notify_test_StrPushS.erl idl_output/notify_test_AnyPushS.erl > idl_output/notify_test_SeqPullS.erl idl_output/notify_test_StrPullS.erl > idl_output/notify_test_AnyPullS.erl idl_output/notify_test_funcs.erl \ > /home/travis/src/main-otp/release/tests/cosNotification_test/idl_output > /usr/bin/install -c -m 644 notification_SUITE.beam grammar_SUITE.beam > eventDB_SUITE.beam generated_SUITE.beam notify_test_impl.beam > /home/travis/src/main-otp/release/tests/cosNotification_test > make[2]: Leaving directory > `/home/travis/src/main-otp/lib/cosNotification/test' > make[1]: Leaving directory > `/home/travis/src/main-otp/lib/cosNotification/test' > if test -f lib/cosProperty/test/Makefile; then \ > (cd lib/cosProperty/test; make > TESTROOT=/home/travis/src/main-otp/release/tests release_tests) || exit $?; > \ > fi > make[1]: Entering directory > `/home/travis/src/main-otp/lib/cosProperty/test' > make -w RELEASE_PATH=/home/travis/src/main-otp/release/tests > release_tests_spec > make[2]: Entering directory > `/home/travis/src/main-otp/lib/cosProperty/test' > /usr/bin/install -c -d > /home/travis/src/main-otp/release/tests/cosProperty_test > /usr/bin/install -c -m 644 cosProperty.spec \ > cosProperty.cover property_SUITE.erl generated_SUITE.erl > /home/travis/src/main-otp/release/tests/cosProperty_test > /usr/bin/install -c -m 644 property_SUITE.beam generated_SUITE.beam > /home/travis/src/main-otp/release/tests/cosProperty_test > make[2]: Leaving directory `/home/travis/src/main-otp/lib/cosProperty/test' > make[1]: Leaving directory `/home/travis/src/main-otp/lib/cosProperty/test' > if test -f lib/cosTime/test/Makefile; then \ > (cd lib/cosTime/test; make TESTROOT=/home/travis/src/main-otp/release/tests > release_tests) || exit $?; \ > fi > make[1]: Entering directory `/home/travis/src/main-otp/lib/cosTime/test' > make -w RELEASE_PATH=/home/travis/src/main-otp/release/tests > release_tests_spec > make[2]: Entering directory `/home/travis/src/main-otp/lib/cosTime/test' > /usr/bin/install -c -d /home/travis/src/main-otp/release/tests/cosTime_test > /usr/bin/install -c -m 644 cosTime.spec \ > cosTime.cover time_SUITE.erl generated_SUITE.erl > /home/travis/src/main-otp/release/tests/cosTime_test > /usr/bin/install -c -m 644 time_SUITE.beam generated_SUITE.beam > /home/travis/src/main-otp/release/tests/cosTime_test > make[2]: Leaving directory `/home/travis/src/main-otp/lib/cosTime/test' > make[1]: Leaving directory `/home/travis/src/main-otp/lib/cosTime/test' > if test -f lib/cosTransactions/test/Makefile; then \ > (cd lib/cosTransactions/test; make > TESTROOT=/home/travis/src/main-otp/release/tests release_tests) || exit $?; > \ > fi > make[1]: Entering directory > `/home/travis/src/main-otp/lib/cosTransactions/test' > make -w RELEASE_PATH=/home/travis/src/main-otp/release/tests > release_tests_spec > make[2]: Entering directory > `/home/travis/src/main-otp/lib/cosTransactions/test' > /usr/bin/install -c -d > /home/travis/src/main-otp/release/tests/cosTransactions_test > /usr/bin/install -c -m 644 etrap_test.idl cosTransactions.spec \ > cosTransactions.cover transactions_SUITE.erl etrap_test_server_impl.erl > etrap_test_lib.erl generated_SUITE.erl etrap_test_lib.hrl > /home/travis/src/main-otp/release/tests/cosTransactions_test > /usr/bin/install -c -m 644 transactions_SUITE.beam > etrap_test_server_impl.beam etrap_test_lib.beam generated_SUITE.beam > /home/travis/src/main-otp/release/tests/cosTransactions_test > /usr/bin/install -c -d > /home/travis/src/main-otp/release/tests/cosTransactions_test/idl_output > /usr/bin/install -c -m 644 idl_output/oe_etrap_test.beam > idl_output/etrap_test_server.beam idl_output/oe_etrap_test.hrl > idl_output/etrap_test_server.hrl idl_output/oe_etrap_test.erl > idl_output/etrap_test_server.erl \ > /home/travis/src/main-otp/release/tests/cosTransactions_test/idl_output > make[2]: Leaving directory > `/home/travis/src/main-otp/lib/cosTransactions/test' > make[1]: Leaving directory > `/home/travis/src/main-otp/lib/cosTransactions/test' > if test -f lib/crypto/test/Makefile; then \ > (cd lib/crypto/test; make TESTROOT=/home/travis/src/main-otp/release/tests > release_tests) || exit $?; \ > fi > make[1]: Entering directory `/home/travis/src/main-otp/lib/crypto/test' > make -w RELEASE_PATH=/home/travis/src/main-otp/release/tests > release_tests_spec > make[2]: Entering directory `/home/travis/src/main-otp/lib/crypto/test' > /home/travis/src/main-otp/make/make_emakefile +debug_info > -I/home/travis/src/main-otp/lib/test_server/include -o. \ > blowfish_SUITE crypto_SUITE > Emakefile > /usr/bin/install -c -d /home/travis/src/main-otp/release/tests/crypto_test > /usr/bin/install -c -m 644 crypto.spec crypto.cover Emakefile > blowfish_SUITE.erl crypto_SUITE.erl > /home/travis/src/main-otp/release/tests/crypto_test > chmod -R u+w /home/travis/src/main-otp/release/tests/crypto_test > make[2]: Leaving directory `/home/travis/src/main-otp/lib/crypto/test' > make[1]: Leaving directory `/home/travis/src/main-otp/lib/crypto/test' > if test -f lib/debugger/test/Makefile; then \ > (cd lib/debugger/test; make > TESTROOT=/home/travis/src/main-otp/release/tests release_tests) || exit $?; > \ > fi > make[1]: Entering directory `/home/travis/src/main-otp/lib/debugger/test' > make -w RELEASE_PATH=/home/travis/src/main-otp/release/tests > release_tests_spec > make[2]: Entering directory `/home/travis/src/main-otp/lib/debugger/test' > /home/travis/src/main-otp/make/make_emakefile +debug_info > -I/home/travis/src/main-otp/lib/test_server/include -o. andor_SUITE > bs_bincomp_SUITE bs_construct_SUITE bs_match_bin_SUITE bs_match_int_SUITE > bs_match_misc_SUITE bs_match_tail_SUITE bs_utf_SUITE bug_SUITE > erl_eval_SUITE dbg_ui_SUITE debugger_SUITE int_SUITE int_break_SUITE > int_eval_SUITE guard_SUITE exception_SUITE fun_SUITE lc_SUITE record_SUITE > trycatch_SUITE test_lib cleanup \ > > Emakefile > /home/travis/src/main-otp/make/make_emakefile +debug_info > -I/home/travis/src/main-otp/lib/test_server/include -o. '*_SUITE_make' \ > >> Emakefile > /usr/bin/install -c -d > /home/travis/src/main-otp/release/tests/debugger_test > /usr/bin/install -c -m 644 Emakefile andor_SUITE.erl bs_bincomp_SUITE.erl > bs_construct_SUITE.erl bs_match_bin_SUITE.erl bs_match_int_SUITE.erl > bs_match_misc_SUITE.erl bs_match_tail_SUITE.erl bs_utf_SUITE.erl > bug_SUITE.erl erl_eval_SUITE.erl dbg_ui_SUITE.erl debugger_SUITE.erl > int_SUITE.erl int_break_SUITE.erl int_eval_SUITE.erl guard_SUITE.erl > exception_SUITE.erl fun_SUITE.erl lc_SUITE.erl record_SUITE.erl > trycatch_SUITE.erl test_lib.erl cleanup.erl > /home/travis/src/main-otp/release/tests/debugger_test > /usr/bin/install -c -m 644 debugger.spec debugger.cover > /home/travis/src/main-otp/release/tests/debugger_test > chmod -R u+w /home/travis/src/main-otp/release/tests/debugger_test > make[2]: Leaving directory `/home/travis/src/main-otp/lib/debugger/test' > make[1]: Leaving directory `/home/travis/src/main-otp/lib/debugger/test' > if test -f lib/dialyzer/test/Makefile; then \ > (cd lib/dialyzer/test; make > TESTROOT=/home/travis/src/main-otp/release/tests release_tests) || exit $?; > \ > fi > make[1]: Entering directory `/home/travis/src/main-otp/lib/dialyzer/test' > make -w RELEASE_PATH=/home/travis/src/main-otp/release/tests > release_tests_spec > make[2]: Entering directory `/home/travis/src/main-otp/lib/dialyzer/test' > /usr/bin/install -c -d > /home/travis/src/main-otp/release/tests/dialyzer_test > chmod -f -R u+w /home/travis/src/main-otp/release/tests/dialyzer_test > /usr/bin/install -c -m 644 dialyzer.spec dialyzer_test_constants.hrl > dialyzer_common.erl file_utils.erl plt_SUITE.erl > /home/travis/src/main-otp/release/tests/dialyzer_test > cd /home/travis/src/main-otp/release/tests/dialyzer_test;\ > erl -make;\ > erl -noshell -run dialyzer_common create_all_suites -s erlang halt > {"init terminating in > do_boot",{undef,[{make,all,[]},{init,start_it,1},{init,start_em,1}]}} > > Crash dump was written to: erl_crash.dump > init terminating in do_boot () > {"init terminating in > do_boot",{undef,[{dialyzer_common,create_all_suites,[]},{init,start_it,1},{init,start_em,1}]}} > > Crash dump was written to: erl_crash.dump > init terminating in do_boot () > make[2]: *** [release_tests_spec] Error 1 > make[2]: Leaving directory `/home/travis/src/main-otp/lib/dialyzer/test' > make[1]: *** [release_tests] Error 2 > make[1]: Leaving directory `/home/travis/src/main-otp/lib/dialyzer/test' > make: *** [lib/dialyzer/test] Error 2 > travis@REDACTED:~/src/main-otp$ > > > -- > *Travis Jensen* > *** > *Read the Software Maven @ http://softwaremaven.innerbrane.com/ > Read my LinkedIn profile @ http://www.linkedin.com/in/travisjensen > Read my Twitter mumblings @ http://twitter.com/SoftwareMaven > Send me email @ travis.jensen@REDACTED > > **What kind of guy calls himself the Software Maven???** > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paolo.negri@REDACTED Fri May 6 10:00:12 2011 From: paolo.negri@REDACTED (Paolo Negri) Date: Fri, 6 May 2011 10:00:12 +0200 Subject: [erlang-questions] hmac sha256 erlang Message-ID: Dear list I did some research on google and I would like to assess the state of the implementation of sha2 in erlang. It seems that such functions are not present in the standard crypto module, and that instead one public implementation is available at https://github.com/vinoski/erlsha2 I would like to know if anyone is using this module in production and if it's stability has been proven. I'd like also to know if someone is aware of an hmac sha-256 implementation built on top of this library. Thanks, Paolo Negri -- Engineering http://www.wooga.com | phone +49-30-8962 5058? | fax +49-30-8964 9064 wooga GmbH | Saarbruecker Str. 38 | 10405 Berlin | Germany Sitz der Gesellschaft: Berlin; HRB 117846 B Registergericht Berlin-Charlottenburg Geschaeftsfuehrung: Jens Begemann, Philipp Moeser From max.lapshin@REDACTED Fri May 6 10:12:26 2011 From: max.lapshin@REDACTED (Max Lapshin) Date: Fri, 6 May 2011 12:12:26 +0400 Subject: [erlang-questions] hmac sha256 erlang In-Reply-To: References: Message-ID: It is used for a long time in erlyvideo (http://github.com/erlyvideo/erlyvideo) and works pretty stable. From raimo+erlang-questions@REDACTED Fri May 6 10:47:48 2011 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Fri, 6 May 2011 10:47:48 +0200 Subject: [erlang-questions] byte() vs. char() use in documentation In-Reply-To: <000701cc0b2e$7719c340$654d49c0$@com> References: <20110502091415.GA6512@erix.ericsson.se> <20110503094549.GA10981@erix.ericsson.se> <201105040533.58985.als@iinet.net.au> <20110504075734.GA16456@erix.ericsson.se> <20110505074921.GA21532@erix.ericsson.se> <065D7456-DE4E-40FF-81E9-ED0002B27550@masklinn.net> <000701cc0b2e$7719c340$654d49c0$@com> Message-ID: <20110506084748.GA12806@erix.ericsson.se> On Thu, May 05, 2011 at 09:12:26AM -0500, David Mercer wrote: > In the past few days, various people wrote: > > > [Various stuff debating Unicode, characters, glyphs, codepoints, code > units, bits, bytes, strings, iolists, etc. etc.] > > I think most programmers are content treating each Unicode codepoint as a > "character," regardless of whether that is strictly correct or not. It is > the unit that is strung together to make strings. A list of Unicode > codepoints seems the reasonable canonical way of representing strings. > Thus: > > char() :: 0..16#10ffff > string() :: [char()] > > The only issue is in the encoding of strings into binary formats, and this > becomes relevant when you have iolists, which mix string pieces with encoded So far all correct and very well. But: iolists are only about bytes, not characters. They are for being able to efficiently construct a byte sequence e.g to send to a driver. > string pieces (binaries). If anyone ever wants to decode an iolist into a > straight string (if this is ever done), it seems reasonable to let the user > specify the encoding of the binaries within the iolist. On the other hand, > if someone is converting an iolist into an encoded binary, we can either (1) > assume the binaries in the iolist are already in the target encoding, (2) > let the programmer specify the encoding of the source iolist binaries and > have them automatically converted to the target encoding. The advantage of > the former is that it allows iolists to represent more than just strings: > they could represent strings with embedded binary components (where > character encoding is irrelevant). There's nothing that says every binary > in an iolist has to decode into a string. I'm going to put that in all-caps > for emphasis: THERE'S NOTHING THAT SAYS EVERY BINARY IN AN IOLIST HAS TO > DECODE INTO A STRING. Thus, I would assume iolists are defined as: All that also very well. There's nothing that says every binary in an iolist has to decode into a string. But: there is just raw binary data in an iolist. > > iolist() :: [char() | binary() | iolist()] Not char(); byte()! iolist() :: [byte() | binary() | iolist()] > > and we have functions available in some library somewhere: > > iolist_to_string(iolist(), SourceEncoding) -> string() > iolist_to_binary(iolist(), TargetEncoding) -> binary(). These exists (simplified): unicode:characters_to_list(characters(), SourceEncoding) -> string() unicode:characters_to_binary( characters(), SourceEncoding, DestEncoding) -> binary() characters() :: [char() | binary()] > > (You'd probably also have iolist_to_string/1 and iolist_to_binary/1, which > assume UTF-8.) We *might* also want to define an iolist_to_binary/3, which unicode:characters_to_list/1 and unicode:characters_to_binary/1 actually does that, i.e assumes utf8 for embedded binaries. erlang:iolist_to_binary/1 assumes latin1 i.e translates nothing. > does convert binaries in the iolist from one encoding to another, but I'd > consider that optional. unicode:characters_to_binary/3 does exactly that. > > Anyone disagree? Just that iolists only should (and does) contain bytes and binaries. That your suggested functions already exist in the module unicode, and that erlang:iolist_to_binary does (and can not be changed) assume latin1. / Raimo > > Cheers, > > DBM > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From rtrlists@REDACTED Fri May 6 10:58:55 2011 From: rtrlists@REDACTED (Robert Raschke) Date: Fri, 6 May 2011 09:58:55 +0100 Subject: [erlang-questions] Webmachine / Mochiweb & client certificates In-Reply-To: <001681FA23024B9AB05D80F310FD0057@srstrong.com> References: <001681FA23024B9AB05D80F310FD0057@srstrong.com> Message-ID: On Thu, May 5, 2011 at 10:06 PM, Steve Strong wrote: > Hi, > > Does anyone out there have any experience with Webmachine (or mochiweb) and > authentication using client certificates? I've had a good google around but > can't see anything that's pointing me in the right direction. Getting > regular SSL up & running was pretty straightforward, as is performing basic > or digest authentication. > > I've also quite easily used curl to exchange a client key, which appeared > to be successful, but within my webmachine resource I can't see anyway to > see that a client cert was presented, nor any details about it that would > allow me to authenticate the user or not. > > Any help would be much appreciated, > > Cheers, > > Steve > > -- > Steve Strong, Director, id3as > twitter.com/srstrong > > There have been a few threads on the list about certificate verification. But in general, what you want to be investigating is the ssl modules verification support, the ssl options (in R14, for R13 it's new_ssl) to have a look at are: {verify, verify_type()} {fail_if_no_peer_cert, boolean()} {verify_fun, fun(ErrorList) -> boolean()} {depth, integer()} I'll be investigating client certificate verification at some point this year. But not sure when yet. Robby -------------- next part -------------- An HTML attachment was scrubbed... URL: From aronisstav@REDACTED Fri May 6 11:25:31 2011 From: aronisstav@REDACTED (Stavros Aronis) Date: Fri, 6 May 2011 02:25:31 -0700 (PDT) Subject: [erlang-questions] Building erlang tests In-Reply-To: Message-ID: <14979963.3255.1304673931457.JavaMail.geo-discussion-forums@vbbcw2> I had a similar issue while developing the patch that seems to cause the crash (it's in sa/dialyzer-tests). Once or twice I got the same error messages which went away as soon as I cleared the old dialyzer_tests directory in the test release and re-run ./otp-build tests . I am positive that make release_tests will work too when you clear the contents of the old directory. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan@REDACTED Fri May 6 11:31:04 2011 From: ivan@REDACTED (Ivan Uemlianin) Date: Fri, 06 May 2011 10:31:04 +0100 Subject: [erlang-questions] How to abstract out common receive clauses? Message-ID: <4DC3BFD8.3060605@llaisdy.com> Dear All % I have a process running continuously in a receive loop. It should act slightly differently depending on one of its state parameters. At the moment I have it like this: process(This, That, a) -> receive {From, do1} -> do1, process(This, That, a); {From, do2} -> do2, process(This, That, a); {From, do3} -> do3, process(This, That, a) end; process(This, That, b) -> receive {From, do1} -> do1, process(This, That, b); {From, do2} -> do2, process(This, That, b); {From, do4} -> do4, process(This, That, b) end. % Most of the receive clauses are common to both versions of process/3 (the real code is more complicated). Is there a way to abstract out the common parts? An "object oriented" language might use inheritance. Prolog might use backtracking, perhaps a bit like this: iProcess(This, That, a) -> receive {From, do3} -> do3, iProcess(This, That, a) end; iProcess(This, That, b) -> receive {From, do4} -> do4, iProcess(This, That, b) end; iProcess(This, That, Other) -> receive {From, do1} -> do1, iProcess(This, That, Other); {From, do2} -> do2, iProcess(This, That, Other) end. % A case would perhaps work, with the proviso that 'generic' receives would be evaluated first: cProcess(This, That, Other) -> receive {From, do1} -> do1, cProcess(This, That, Other); {From, do2} -> do2, cProcess(This, That, Other) end, case Other of a -> receive {From, do3} -> do3, cProcess(This, That, Other) end; b -> receive {From, do4} -> do4, cProcess(This, That, Other) end end. % Is there a canonical way of dealing with this problem (other than copy-and-paste)? With thanks and best wishes Ivan -- ============================================================ Ivan A. Uemlianin Speech Technology Research and Development ivan@REDACTED www.llaisdy.com llaisdy.wordpress.com www.linkedin.com/in/ivanuemlianin "Froh, froh! Wie seine Sonnen, seine Sonnen fliegen" (Schiller, Beethoven) ============================================================ From lenartlad@REDACTED Fri May 6 11:57:36 2011 From: lenartlad@REDACTED (Ladislav Lenart) Date: Fri, 06 May 2011 11:57:36 +0200 Subject: [erlang-questions] How to abstract out common receive clauses? In-Reply-To: <4DC3BFD8.3060605@llaisdy.com> References: <4DC3BFD8.3060605@llaisdy.com> Message-ID: <4DC3C610.6050705@volny.cz> Hello. I think something like this should work (not tested however!): process(This, That, X) -> receive {From, do1} when X == a; X == b -> do1, process(This, That, X); {From, do2} when X == a; X == b -> do2, process(This, That, X); {From, do3} when X == a -> do3, process(This, That, X); {From, do4} when X == b -> do4, process(This, That, X) end. In addition, you can also define helper macros like: -define(is_a_or_b(X), X == a; X == b). -define(is_a(X), X == a). -define(is_b(X), X == b). and rewrite the above using them. HTH, Ladislav Lenart On 6.5.2011 11:31, Ivan Uemlianin wrote: > Dear All > > % I have a process running continuously in a receive loop. It should act slightly differently depending on one of its state parameters. At the moment I have it like this: > > process(This, That, a) -> > receive > {From, do1} -> > do1, > process(This, That, a); > {From, do2} -> > do2, > process(This, That, a); > {From, do3} -> > do3, > process(This, That, a) > end; > > process(This, That, b) -> > receive > {From, do1} -> > do1, > process(This, That, b); > {From, do2} -> > do2, > process(This, That, b); > {From, do4} -> > do4, > process(This, That, b) > end. > > > % Most of the receive clauses are common to both versions of process/3 (the real code is more complicated). Is there a way to abstract out the common parts? An "object oriented" language might use > inheritance. Prolog might use backtracking, perhaps a bit like this: > > iProcess(This, That, a) -> > receive > {From, do3} -> > do3, > iProcess(This, That, a) > end; > > iProcess(This, That, b) -> > receive > {From, do4} -> > do4, > iProcess(This, That, b) > end; > > iProcess(This, That, Other) -> > receive > {From, do1} -> > do1, > iProcess(This, That, Other); > {From, do2} -> > do2, > iProcess(This, That, Other) > end. > > > % A case would perhaps work, with the proviso that 'generic' receives would be evaluated first: > > cProcess(This, That, Other) -> > receive > {From, do1} -> > do1, > cProcess(This, That, Other); > {From, do2} -> > do2, > cProcess(This, That, Other) > end, > case Other of > a -> > receive > {From, do3} -> > do3, > cProcess(This, That, Other) > end; > b -> > receive > {From, do4} -> > do4, > cProcess(This, That, Other) > end > end. > > > % Is there a canonical way of dealing with this problem (other than copy-and-paste)? > > With thanks and best wishes > > Ivan > From torben.lehoff@REDACTED Fri May 6 12:54:52 2011 From: torben.lehoff@REDACTED (Torben Hoffmann) Date: Fri, 6 May 2011 12:54:52 +0200 Subject: [erlang-questions] How to abstract out common receive clauses? In-Reply-To: <4DC3BFD8.3060605@llaisdy.com> References: <4DC3BFD8.3060605@llaisdy.com> Message-ID: -module(ivan). -compile(export_all). process(This,That,State) -> receive {From, do1} -> From ! do1, process(This,That,State); {From, do2 } -> From ! do2, process(This,That,State); {From, do3} when State=:=a -> From ! do3, process(This,That,b); {From, do4} when State=:=b -> From ! do4, process(This,That,a) end. listen(P) -> receive {send,M} -> P ! {self(),M}, listen(P); M -> io:format("listen got: ~p~n",[M]), listen(P) end. Cheers, Torben On Fri, May 6, 2011 at 11:31, Ivan Uemlianin wrote: > Dear All > > % I have a process running continuously in a receive loop. It should act > slightly differently depending on one of its state parameters. At the > moment I have it like this: > > process(This, That, a) -> > receive > {From, do1} -> > do1, > process(This, That, a); > {From, do2} -> > do2, > process(This, That, a); > {From, do3} -> > do3, > process(This, That, a) > end; > > process(This, That, b) -> > receive > {From, do1} -> > do1, > process(This, That, b); > {From, do2} -> > do2, > process(This, That, b); > {From, do4} -> > do4, > process(This, That, b) > end. > > > % Most of the receive clauses are common to both versions of process/3 (the > real code is more complicated). Is there a way to abstract out the common > parts? An "object oriented" language might use inheritance. Prolog might > use backtracking, perhaps a bit like this: > > iProcess(This, That, a) -> > receive > {From, do3} -> > do3, > iProcess(This, That, a) > end; > > iProcess(This, That, b) -> > receive > {From, do4} -> > do4, > iProcess(This, That, b) > end; > > iProcess(This, That, Other) -> > receive > {From, do1} -> > do1, > iProcess(This, That, Other); > {From, do2} -> > do2, > iProcess(This, That, Other) > end. > > > % A case would perhaps work, with the proviso that 'generic' receives would > be evaluated first: > > cProcess(This, That, Other) -> > receive > {From, do1} -> > do1, > cProcess(This, That, Other); > {From, do2} -> > do2, > cProcess(This, That, Other) > end, > case Other of > a -> > receive > {From, do3} -> > do3, > cProcess(This, That, Other) > end; > b -> > receive > {From, do4} -> > do4, > cProcess(This, That, Other) > end > end. > > > % Is there a canonical way of dealing with this problem (other than > copy-and-paste)? > > With thanks and best wishes > > Ivan > > -- > ============================================================ > Ivan A. Uemlianin > Speech Technology Research and Development > > ivan@REDACTED > www.llaisdy.com > llaisdy.wordpress.com > www.linkedin.com/in/ivanuemlianin > > "Froh, froh! Wie seine Sonnen, seine Sonnen fliegen" > (Schiller, Beethoven) > ============================================================ > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- http://www.linkedin.com/in/torbenhoffmann -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan@REDACTED Fri May 6 13:12:06 2011 From: ivan@REDACTED (Ivan Uemlianin) Date: Fri, 06 May 2011 12:12:06 +0100 Subject: [erlang-questions] How to abstract out common receive clauses? In-Reply-To: References: <4DC3BFD8.3060605@llaisdy.com> Message-ID: <4DC3D786.6020002@llaisdy.com> Thanks! I knew there would be something. Time for me to start using guards. Best wishes Ivan On 06/05/2011 11:54, Torben Hoffmann wrote: > -module(ivan). > > -compile(export_all). > > > process(This,That,State) -> > > receive > {From, do1} -> > From ! do1, > process(This,That,State); > {From, do2 } -> > From ! do2, > process(This,That,State); > {From, do3} when State=:=a -> > From ! do3, > process(This,That,b); > {From, do4} when State=:=b -> > From ! do4, > process(This,That,a) > end. > > listen(P) -> > receive > {send,M} -> > P ! {self(),M}, > listen(P); > M -> > io:format("listen got: ~p~n",[M]), > listen(P) > end. > > Cheers, > Torben > > > On Fri, May 6, 2011 at 11:31, Ivan Uemlianin > wrote: > > Dear All > > % I have a process running continuously in a receive loop. It > should act slightly differently depending on one of its state > parameters. At the moment I have it like this: > > process(This, That, a) -> > receive > {From, do1} -> > do1, > process(This, That, a); > {From, do2} -> > do2, > process(This, That, a); > {From, do3} -> > do3, > process(This, That, a) > end; > > process(This, That, b) -> > receive > {From, do1} -> > do1, > process(This, That, b); > {From, do2} -> > do2, > process(This, That, b); > {From, do4} -> > do4, > process(This, That, b) > end. > > > % Most of the receive clauses are common to both versions of > process/3 (the real code is more complicated). Is there a way to > abstract out the common parts? An "object oriented" language > might use inheritance. Prolog might use backtracking, perhaps a > bit like this: > > iProcess(This, That, a) -> > receive > {From, do3} -> > do3, > iProcess(This, That, a) > end; > > iProcess(This, That, b) -> > receive > {From, do4} -> > do4, > iProcess(This, That, b) > end; > > iProcess(This, That, Other) -> > receive > {From, do1} -> > do1, > iProcess(This, That, Other); > {From, do2} -> > do2, > iProcess(This, That, Other) > end. > > > % A case would perhaps work, with the proviso that 'generic' > receives would be evaluated first: > > cProcess(This, That, Other) -> > receive > {From, do1} -> > do1, > cProcess(This, That, Other); > {From, do2} -> > do2, > cProcess(This, That, Other) > end, > case Other of > a -> > receive > {From, do3} -> > do3, > cProcess(This, That, Other) > end; > b -> > receive > {From, do4} -> > do4, > cProcess(This, That, Other) > end > end. > > > % Is there a canonical way of dealing with this problem (other > than copy-and-paste)? > > With thanks and best wishes > > Ivan > > -- > ============================================================ > Ivan A. Uemlianin > Speech Technology Research and Development > > ivan@REDACTED > www.llaisdy.com > llaisdy.wordpress.com > www.linkedin.com/in/ivanuemlianin > > > "Froh, froh! Wie seine Sonnen, seine Sonnen fliegen" > (Schiller, Beethoven) > ============================================================ > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > > -- > http://www.linkedin.com/in/torbenhoffmann -- ============================================================ Ivan A. Uemlianin Speech Technology Research and Development ivan@REDACTED www.llaisdy.com llaisdy.wordpress.com www.linkedin.com/in/ivanuemlianin "Froh, froh! Wie seine Sonnen, seine Sonnen fliegen" (Schiller, Beethoven) ============================================================ From torben.lehoff@REDACTED Fri May 6 13:21:41 2011 From: torben.lehoff@REDACTED (Torben Hoffmann) Date: Fri, 6 May 2011 13:21:41 +0200 Subject: [erlang-questions] How to abstract out common receive clauses? In-Reply-To: <4DC3D786.6020002@llaisdy.com> References: <4DC3BFD8.3060605@llaisdy.com> <4DC3D786.6020002@llaisdy.com> Message-ID: That will guard you from many lines of repetitive code! On Fri, May 6, 2011 at 13:12, Ivan Uemlianin wrote: > Thanks! I knew there would be something. Time for me to start using > guards. > > Best wishes > > Ivan > > > > On 06/05/2011 11:54, Torben Hoffmann wrote: > >> -module(ivan). >> >> -compile(export_all). >> >> >> process(This,That,State) -> >> >> receive >> {From, do1} -> >> From ! do1, >> process(This,That,State); >> {From, do2 } -> >> From ! do2, >> process(This,That,State); >> {From, do3} when State=:=a -> >> From ! do3, >> process(This,That,b); >> {From, do4} when State=:=b -> >> From ! do4, >> process(This,That,a) >> end. >> >> listen(P) -> >> receive >> {send,M} -> >> P ! {self(),M}, >> listen(P); >> M -> >> io:format("listen got: ~p~n",[M]), >> listen(P) >> end. >> >> Cheers, >> Torben >> >> >> On Fri, May 6, 2011 at 11:31, Ivan Uemlianin > ivan@REDACTED>> wrote: >> >> Dear All >> >> % I have a process running continuously in a receive loop. It >> should act slightly differently depending on one of its state >> parameters. At the moment I have it like this: >> >> process(This, That, a) -> >> receive >> {From, do1} -> >> do1, >> process(This, That, a); >> {From, do2} -> >> do2, >> process(This, That, a); >> {From, do3} -> >> do3, >> process(This, That, a) >> end; >> >> process(This, That, b) -> >> receive >> {From, do1} -> >> do1, >> process(This, That, b); >> {From, do2} -> >> do2, >> process(This, That, b); >> {From, do4} -> >> do4, >> process(This, That, b) >> end. >> >> >> % Most of the receive clauses are common to both versions of >> process/3 (the real code is more complicated). Is there a way to >> abstract out the common parts? An "object oriented" language >> might use inheritance. Prolog might use backtracking, perhaps a >> bit like this: >> >> iProcess(This, That, a) -> >> receive >> {From, do3} -> >> do3, >> iProcess(This, That, a) >> end; >> >> iProcess(This, That, b) -> >> receive >> {From, do4} -> >> do4, >> iProcess(This, That, b) >> end; >> >> iProcess(This, That, Other) -> >> receive >> {From, do1} -> >> do1, >> iProcess(This, That, Other); >> {From, do2} -> >> do2, >> iProcess(This, That, Other) >> end. >> >> >> % A case would perhaps work, with the proviso that 'generic' >> receives would be evaluated first: >> >> cProcess(This, That, Other) -> >> receive >> {From, do1} -> >> do1, >> cProcess(This, That, Other); >> {From, do2} -> >> do2, >> cProcess(This, That, Other) >> end, >> case Other of >> a -> >> receive >> {From, do3} -> >> do3, >> cProcess(This, That, Other) >> end; >> b -> >> receive >> {From, do4} -> >> do4, >> cProcess(This, That, Other) >> end >> end. >> >> >> % Is there a canonical way of dealing with this problem (other >> than copy-and-paste)? >> >> With thanks and best wishes >> >> Ivan >> >> -- ============================================================ >> Ivan A. Uemlianin >> Speech Technology Research and Development >> >> ivan@REDACTED >> www.llaisdy.com >> llaisdy.wordpress.com >> >> www.linkedin.com/in/ivanuemlianin >> >> >> >> "Froh, froh! Wie seine Sonnen, seine Sonnen fliegen" >> (Schiller, Beethoven) >> ============================================================ >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> >> >> -- >> http://www.linkedin.com/in/torbenhoffmann >> > > > -- > ============================================================ > Ivan A. Uemlianin > Speech Technology Research and Development > > ivan@REDACTED > www.llaisdy.com > llaisdy.wordpress.com > www.linkedin.com/in/ivanuemlianin > > "Froh, froh! Wie seine Sonnen, seine Sonnen fliegen" > (Schiller, Beethoven) > ============================================================ > > -- http://www.linkedin.com/in/torbenhoffmann -------------- next part -------------- An HTML attachment was scrubbed... URL: From steven.charles.davis@REDACTED Fri May 6 14:52:47 2011 From: steven.charles.davis@REDACTED (Steve Davis) Date: Fri, 6 May 2011 05:52:47 -0700 (PDT) Subject: [erlang-questions] hmac sha256 erlang In-Reply-To: References: Message-ID: On May 6, 3:00?am, Paolo Negri wrote: > I'd like also to know if someone is aware of an hmac sha-256 > implementation built on top of this library. For HMAC-NNN with the sha2 library, you can do something like... % HMAC SHA -define(SHA_224_BLOCKSIZE, 64). -define(SHA_256_BLOCKSIZE, 64). -define(SHA_384_BLOCKSIZE, 128). -define(SHA_512_BLOCKSIZE, 128). % HMAC test vectors at http://tools.ietf.org/html/rfc4231 hmac(Key, Data) -> crypto:sha_mac(Key, Data). hmac224(Key, Data) -> hmac(Key, Data, fun sha2:hexdigest224/1, ?SHA_224_BLOCKSIZE). hmac256(Key, Data) -> hmac(Key, Data, fun sha2:hexdigest256/1, ?SHA_256_BLOCKSIZE). hmac384(Key, Data) -> hmac(Key, Data, fun sha2:hexdigest384/1, ?SHA_384_BLOCKSIZE). hmac512(Key, Data) -> hmac(Key, Data, fun sha2:hexdigest512/1, ?SHA_512_BLOCKSIZE). % hmac(Key, Data, Hash, Blocksize) when is_binary(Key), is_binary(Data) - > HashKey = case Blocksize - byte_size(Key) of X when X < 0 -> KeyDigest = Hash(Key), Pad = Blocksize - byte_size(KeyDigest), <>; X when X > 0 -> <>; X when X =:= 0 -> Key end, IPad = list_to_binary(lists:duplicate(Blocksize, 16#36)), OPad = list_to_binary(lists:duplicate(Blocksize, 16#5c)), H1 = Hash(<<(crypto:exor(HashKey, IPad))/binary, Data/binary>>), Hash(<<(crypto:exor(HashKey, OPad))/binary, H1/binary>>). From steven.charles.davis@REDACTED Fri May 6 15:06:28 2011 From: steven.charles.davis@REDACTED (Steve Davis) Date: Fri, 6 May 2011 06:06:28 -0700 (PDT) Subject: [erlang-questions] hmac sha256 erlang In-Reply-To: References: Message-ID: ...though now I would favor binary:copy instead of list_to_binary(lists:duplicate()), but that depends on what OTP version you have... /s From paolo.negri@REDACTED Fri May 6 15:19:33 2011 From: paolo.negri@REDACTED (Paolo Negri) Date: Fri, 6 May 2011 15:19:33 +0200 Subject: [erlang-questions] hmac sha256 erlang In-Reply-To: References: Message-ID: On Fri, May 6, 2011 at 3:06 PM, Steve Davis wrote: > ...though now I would favor binary:copy instead of > list_to_binary(lists:duplicate()), but that depends on what OTP > version you have... We're currently using R14B02 Thanks for all the helpful answers. Paolo From dmercer@REDACTED Fri May 6 15:37:41 2011 From: dmercer@REDACTED (David Mercer) Date: Fri, 6 May 2011 08:37:41 -0500 Subject: [erlang-questions] byte() vs. char() use in documentation In-Reply-To: <20110506084748.GA12806@erix.ericsson.se> References: <20110502091415.GA6512@erix.ericsson.se> <20110503094549.GA10981@erix.ericsson.se> <201105040533.58985.als@iinet.net.au> <20110504075734.GA16456@erix.ericsson.se> <20110505074921.GA21532@erix.ericsson.se> <065D7456-DE4E-40FF-81E9-ED0002B27550@masklinn.net> <000701cc0b2e$7719c340$654d49c0$@com> <20110506084748.GA12806@erix.ericsson.se> Message-ID: <008e01cc0bf2$c759bd00$560d3700$@com> On Friday, May 06, 2011, Raimo Niskanen wrote: > But: iolists are only about bytes, not characters. They are for being > able to efficiently construct a byte sequence e.g to send to a driver. Aha! Yes, you are absolutely right. I got caught in the mistaken idea that iolists are, at their core, strings, with maybe some binary data sprinkled in. But as you so rightly point out, iolists are not about an easy-to-construct representation of strings, they're about easy-to-construct representation of bytes for I/O purposes (probably mainly O). > But: there is just raw binary data in an iolist. > > > > > iolist() :: [char() | binary() | iolist()] > > Not char(); byte()! > iolist() :: [byte() | binary() | iolist()] You are correct. You are correct. You are correct. Cheers, David From vinoski@REDACTED Fri May 6 15:38:28 2011 From: vinoski@REDACTED (Steve Vinoski) Date: Fri, 6 May 2011 09:38:28 -0400 Subject: [erlang-questions] hmac sha256 erlang In-Reply-To: References: Message-ID: On Fri, May 6, 2011 at 4:00 AM, Paolo Negri wrote: > Dear list > > I did some research on google and I would like to assess the state of > the implementation of sha2 in erlang. > It seems that such functions are not present in the standard crypto > module, and that instead one public implementation is available at > https://github.com/vinoski/erlsha2 > I would like to know if anyone is using this module in production and > if it's stability has been proven. It passes all test vectors I've thrown at it. If you find any that don't work, please let me know. The code has been around for several years, originally just served off my website. The original version was pure Erlang, which proved to be too slow for most, but a number of people have emailed me over the years saying they were using it because speed wasn't an issue for them. That original code is still present in the github repo as the fallback implementations for the NIFs, which are the newest part of the github version. The NIFs are basically C translations of the original Erlang code, and so are operationally the same, though of course I paid special attention to avoiding the usual problems you get in C with pointer problems and buffer overflows. The C code is also much faster of course -- on my 4+ year old MBPro it takes 28 seconds to run the test suite without the NIFs, 0.75 seconds with the NIFs. If you have any problems with it, just let me know. --steve From sasa555@REDACTED Fri May 6 16:17:23 2011 From: sasa555@REDACTED (sasa) Date: Fri, 6 May 2011 16:17:23 +0200 Subject: [erlang-questions] mochiweb https/ssl In-Reply-To: References: <1304632965.1894.13.camel@sasa-laptop> Message-ID: Hello, thank you for the reply. It helped me move in the right direction, but I still can't figure out the underlying problem. I have configured stunnel on the test server. The stunnel acted as a https proxy to the http erlang server on the same machine. The behavior was somewhat better - the load test of about 2000 requests would work correctly for about 30 seconds, then all subsequent requests would fail. When using erlang ssl, such load test would fail immediately. I have then moved stunnel proxy to a separate server, and then it worked perfectly. Currently, I am suspecting that cpu load might be the problem. When I had stunnel on the same machine as erlang server, cpu load was going high. The same thing happened when I used erlang ssl. When stunnel is on a separate machine, the cpu load on both machines is fairly low. I cannot explain why it works better with stunnel. Do I have to manually configure ssl sessions when using erlang? As I mentioned earlier, the client does long polling i.e. it sends an request, and as soon as the request is responded, the new one is made. Is it possible that ssl handhsake occurs for every request? Any other ideas? Best regards, Sasa On Fri, May 6, 2011 at 5:51 AM, Chandru wrote: > Hi, > > To rule out any issues with the implementation of ssl, I would suggest you > use stunnel (http://www.stunnel.org) to firstly do the SSL handling for you. > If your https tests work properly with that, then we know it is an issue > with the OTP implementation of SSL. If you still have the same problems, it > could be a problem with your setup. > > cheers > Chandru > From steve@REDACTED Fri May 6 16:26:42 2011 From: steve@REDACTED (Steve Strong) Date: Fri, 6 May 2011 16:26:42 +0200 Subject: [erlang-questions] Webmachine / Mochiweb & client certificates In-Reply-To: References: <001681FA23024B9AB05D80F310FD0057@srstrong.com> Message-ID: <320E1620EA034C4DAA16802896894E5A@srstrong.com> Thanks for the replies - currently, I'm using the nginx approach which is working perfectly. Cheers, Steve -- Steve Strong, Director, id3as twitter.com/srstrong On Friday, 6 May 2011 at 10:58, Robert Raschke wrote: > > On Thu, May 5, 2011 at 10:06 PM, Steve Strong wrote: > > Hi, > > > > Does anyone out there have any experience with Webmachine (or mochiweb) and authentication using client certificates? I've had a good google around but can't see anything that's pointing me in the right direction. Getting regular SSL up & running was pretty straightforward, as is performing basic or digest authentication. > > > > I've also quite easily used curl to exchange a client key, which appeared to be successful, but within my webmachine resource I can't see anyway to see that a client cert was presented, nor any details about it that would allow me to authenticate the user or not. > > > > Any help would be much appreciated, > > > > Cheers, > > > > Steve > > > > -- > > Steve Strong, Director, id3as > > twitter.com/srstrong > > There have been a few threads on the list about certificate verification. But in general, what you want to be investigating is the ssl modules verification support, the ssl options (in R14, for R13 it's new_ssl) to have a look at are: > > {verify, verify_type()} > {fail_if_no_peer_cert, boolean()} > {verify_fun, fun(ErrorList) -> boolean()} > {depth, integer()} > > I'll be investigating client certificate verification at some point this year. But not sure when yet. > > Robby > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chad@REDACTED Fri May 6 18:19:19 2011 From: chad@REDACTED (Chad DePue) Date: Fri, 6 May 2011 13:19:19 -0300 Subject: [erlang-questions] Success Stories of Erlang Development In-Reply-To: <201103030430.44279.als@iinet.net.au> References: <810922686.10234471298947933374.JavaMail.root@ucimail4.uci.cu> <4D6CFBD3.8000708@erlang-solutions.com> <201103030430.44279.als@iinet.net.au> Message-ID: We just released VH1 Co-Star- an Erlang-powered TV Co-viewing iPad application. Server is Erlang / CouchDB / Redis. It appears to be chat on the surface but it's more of a big data processor churning through twitter and facebook messages and curating the best set for each user... Chad DePue skype: cdepue inakanetworks.com - iOS, Erlang, Ruby, and Java Consulting On Wed, Mar 2, 2011 at 2:30 PM, Anthony Shipman wrote: > The product described at www.symstream.com is mostly Erlang on the server > side. > -- > Anthony Shipman Mamas don't let your babies > als@REDACTED grow up to be outsourced. > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Fri May 6 18:25:31 2011 From: max.lapshin@REDACTED (Max Lapshin) Date: Fri, 6 May 2011 20:25:31 +0400 Subject: [erlang-questions] Success Stories of Erlang Development In-Reply-To: References: <810922686.10234471298947933374.JavaMail.root@ucimail4.uci.cu> <4D6CFBD3.8000708@erlang-solutions.com> <201103030430.44279.als@iinet.net.au> Message-ID: I'm developing http://erlyvideo.org/ for a long time and I can say: it would be impossible to do it on any other platform. Erlang is cool, because your prototype code is production code: just obey some small set of rules. From ingela@REDACTED Fri May 6 21:30:04 2011 From: ingela@REDACTED (Ingela Andin) Date: Fri, 6 May 2011 21:30:04 +0200 Subject: [erlang-questions] mochiweb https/ssl In-Reply-To: References: <1304632965.1894.13.camel@sasa-laptop> Message-ID: Hi! 2011/5/6 sasa : > Hello, > thank you for the reply. It helped me move in the right direction, but > I still can't figure out the underlying problem. > > I have configured stunnel on the test server. The stunnel acted as a > https proxy to the http erlang server on the same machine. > > The behavior was somewhat better - the load test of about 2000 > requests would work correctly for about 30 seconds, then all > subsequent requests would fail. When using erlang ssl, such load test > would fail immediately. Where you using the old or the new erlang ssl implementation? Old ssl scales poorly. > I have then moved stunnel proxy to a separate server, and then it > worked perfectly. > > Currently, I am suspecting that cpu load might be the problem. When I > had stunnel on the same machine as erlang server, cpu load was going > high. The same thing happened when I used erlang ssl. When stunnel is > on a separate machine, the cpu load on both machines is fairly low. > > I cannot explain why it works better with stunnel. Do I have to > manually configure ssl sessions when using erlang? As I mentioned > earlier, the client does long polling i.e. it sends an request, and as > soon as the request is responded, the new one is made. Is it possible > that ssl handhsake occurs for every request? If you use new ssl and not make any special configuration it will always automatically try to reuse sessions. (The server can refuse to reuse a session if it wants to) How the old implementation works I can not remember from the top of my head but if you are using the old one I recomend upgrading to the new one. The new one is default in R14* and before that the old one is default. I recomend R14. Regards Ingela Erlang/OTP team - Ericsson AB From sasa555@REDACTED Fri May 6 21:38:26 2011 From: sasa555@REDACTED (sasa) Date: Fri, 06 May 2011 21:38:26 +0200 Subject: [erlang-questions] mochiweb https/ssl In-Reply-To: References: <1304632965.1894.13.camel@sasa-laptop> Message-ID: <1304710706.1860.3.camel@sasa-laptop> Hello, On Fri, 2011-05-06 at 21:30 +0200, Ingela Andin wrote: > Where you using the old or the new erlang ssl implementation? Old ssl > scales poorly. > If you use new ssl and not make any special configuration it will > always automatically > try to reuse sessions. (The server can refuse to reuse a session if it wants to) > How the old implementation works I can not remember from the > top of my head but if you are using the old one I recomend upgrading > to the new one. > The new one is default in R14* and before that the old one is default. > I recomend R14. I am using erlang R14B02, so I suppose it is the new ssl. Is there any way I can verify which implementation is actually used? Could it be that I was missing some dependency during the compilation of the erlang and the old ssl is actually used even though it is the version R14? Sasa -------------- next part -------------- An HTML attachment was scrubbed... URL: From ingela@REDACTED Fri May 6 21:42:18 2011 From: ingela@REDACTED (Ingela Andin) Date: Fri, 6 May 2011 21:42:18 +0200 Subject: [erlang-questions] Webmachine / Mochiweb & client certificates In-Reply-To: <001681FA23024B9AB05D80F310FD0057@srstrong.com> References: <001681FA23024B9AB05D80F310FD0057@srstrong.com> Message-ID: Hi! I can not say anything about Webmachine (or mochiweb) but new erlang ssl supports authentication of the client. I recommend using the latest R14 release to make sure you get all improvments that we have done regarding this functionality. Regards Ingela Erlang/OTP team - Ericsson AB 2011/5/5 Steve Strong : > Hi, > > Does anyone out there have any experience with Webmachine (or mochiweb) and > authentication using client certificates? ?I've had a good google around but > can't see anything that's pointing me in the right direction. ?Getting > regular SSL up & running was pretty straightforward, as is performing basic > or digest authentication. > > I've also quite easily used curl to exchange a client key, which appeared to > be successful, but within my webmachine resource I can't see anyway to see > that a client cert was presented, nor any details about it that would allow > me to authenticate the user or not. > Any help would be much appreciated, > Cheers, > Steve > -- > Steve Strong, Director, id3as > twitter.com/srstrong > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > From chandrashekhar.mullaparthi@REDACTED Fri May 6 22:30:27 2011 From: chandrashekhar.mullaparthi@REDACTED (Chandru) Date: Fri, 6 May 2011 21:30:27 +0100 Subject: [erlang-questions] mochiweb https/ssl In-Reply-To: References: <1304632965.1894.13.camel@sasa-laptop> Message-ID: Hi Sasa, On 6 May 2011 15:17, sasa wrote: > Hello, > thank you for the reply. It helped me move in the right direction, but > I still can't figure out the underlying problem. > > I have configured stunnel on the test server. The stunnel acted as a > https proxy to the http erlang server on the same machine. > > The behavior was somewhat better - the load test of about 2000 > requests would work correctly for about 30 seconds, then all > subsequent requests would fail. When using erlang ssl, such load test > would fail immediately. > Which side do you think they failed? Server or client? > I have then moved stunnel proxy to a separate server, and then it > worked perfectly. > Currently, I am suspecting that cpu load might be the problem. When I > had stunnel on the same machine as erlang server, cpu load was going > high. The same thing happened when I used erlang ssl. When stunnel is > on a separate machine, the cpu load on both machines is fairly low. > That is quite strange. What is the spec of the machine? This might be a peculiarity of the virtual instances you get on EC2. Is there any chance you can repeat this test on dedicated hardware? When running both on the same machine, have you monitored which process eats more CPU? beam or stunnel? I remember a similar situation in the past trying to run load tests on EC2. It was hard to get a predictable set of results when load testing because the performance for the same test used to fluctuate. I cannot explain why it works better with stunnel. Do I have to > manually configure ssl sessions when using erlang? As I mentioned > earlier, the client does long polling i.e. it sends an request, and as > soon as the request is responded, the new one is made. Is it possible > that ssl handhsake occurs for every request? > I doubt the handshake occurs for every request. It might have something to do with the fact that stunnel is written in C so is likely to benefit in terms of performance. You could try hipe compilation of the ssl application to see if that gives you any better performance. cheers Chandru > On Fri, May 6, 2011 at 5:51 AM, Chandru > wrote: > > Hi, > > > > To rule out any issues with the implementation of ssl, I would suggest > you > > use stunnel (http://www.stunnel.org) to firstly do the SSL handling for > you. > > If your https tests work properly with that, then we know it is an issue > > with the OTP implementation of SSL. If you still have the same problems, > it > > could be a problem with your setup. > > > > cheers > > Chandru > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.virding@REDACTED Fri May 6 23:43:44 2011 From: robert.virding@REDACTED (Robert Virding) Date: Fri, 6 May 2011 21:43:44 +0000 (GMT) Subject: [erlang-questions] hmac sha256 erlang In-Reply-To: Message-ID: <199799912.152361304718224053.JavaMail.root@zimbra> Why would you want to do binary:copy here? It is not what it is intended for. Robert ----- "Steve Davis" wrote: > ...though now I would favor binary:copy instead of > list_to_binary(lists:duplicate()), but that depends on what OTP > version you have... > > /s > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From travis.jensen@REDACTED Sat May 7 00:20:18 2011 From: travis.jensen@REDACTED (Travis Jensen) Date: Fri, 6 May 2011 16:20:18 -0600 Subject: [erlang-questions] Building on mac Message-ID: I'm building 'dev' on OS X and am seeing the following problem. Now sure what is causing is, since I've built before: gcc -mdynamic-no-pic -m64 -g -O3 -fomit-frame-pointer -I/Users/travis/src2/foss/otp/erts/i386-apple-darwin10.7.0 -no-cpp-precomp -D_XOPEN_SOURCE -DERTS_SMP -DHAVE_CONFIG_H -Wall -Wstrict-prototypes -Wmissing-prototypes -Wdeclaration-after-statement -DUSE_THREADS -D_THREAD_SAFE -D_REENTRANT -DPOSIX_THREADS -Ii386-apple-darwin10.7.0/opt/smp -Ibeam -Isys/unix -Isys/common -Ii386-apple-darwin10.7.0 -Izlib -Ipcre -Ihipe -I../include -I../include/i386-apple-darwin10.7.0 -I../include/internal -I../include/internal/i386-apple-darwin10.7.0 -c beam/erl_bif_info.c -o obj/i386-apple-darwin10.7.0/opt/smp/erl_bif_info.o beam/erl_bif_info.c: In function 'system_info_1': beam/erl_bif_info.c:2003: error: 'am_amd64' undeclared (first use in this function) beam/erl_bif_info.c:2003: error: (Each undeclared identifier is reported only once beam/erl_bif_info.c:2003: error: for each function it appears in.) make[3]: *** [obj/i386-apple-darwin10.7.0/opt/smp/erl_bif_info.o] Error 1 make[2]: *** [opt] Error 2 make[1]: *** [smp] Error 2 make: *** [emulator] Error 2 This is OS X 10.7. I did the following: $ ./otp_build configure --enable-darwin-64bit --prefix=/Users/travis/opt/erlang $ ./otp_build release Any ideas? tj -- *Travis Jensen* *** *Read the Software Maven @ http://softwaremaven.innerbrane.com/ Read my LinkedIn profile @ http://www.linkedin.com/in/travisjensen Read my Twitter mumblings @ http://twitter.com/SoftwareMaven Send me email @ travis.jensen@REDACTED **What kind of guy calls himself the Software Maven???** -------------- next part -------------- An HTML attachment was scrubbed... URL: From sasa555@REDACTED Sat May 7 01:09:35 2011 From: sasa555@REDACTED (sasa) Date: Sat, 07 May 2011 01:09:35 +0200 Subject: [erlang-questions] mochiweb https/ssl In-Reply-To: References: <1304632965.1894.13.camel@sasa-laptop> Message-ID: <1304723375.1860.46.camel@sasa-laptop> Oops, I have accidentally replied to sender, rather than to the group. Sorry :-( Here goes again for the group... Hello Chandru, thank you for taking the time to read my posts and respond! On Fri, 2011-05-06 at 21:30 +0100, Chandru wrote: > The behavior was somewhat better - the load test of about 2000 > requests would work correctly for about 30 seconds, then all > subsequent requests would fail. When using erlang ssl, such > load test > would fail immediately. > > > Which side do you think they failed? Server or client? It's a very good question, since you use the word think :-) I strongly suspect it is the server. There are couple of reasons, most significant one being that the client works perfectly in the configuration where stunnel is on the separate machine. > I have then moved stunnel proxy to a separate server, and then > it > worked perfectly. > > Currently, I am suspecting that cpu load might be the problem. > When I > had stunnel on the same machine as erlang server, cpu load was > going > high. The same thing happened when I used erlang ssl. When > stunnel is > on a separate machine, the cpu load on both machines is fairly > low. > > > That is quite strange. What is the spec of the machine? This might be > a peculiarity of the virtual instances you get on EC2. Is there any > chance you can repeat this test on dedicated hardware? When running > both on the same machine, have you monitored which process eats more > CPU? beam or stunnel? It is the "large" EC2 instance with two cores and 7.5 GB of memory. The same type of instance sustained 12 hours of http load testing with 20 000 clients and is running the production system serving about 700 http users on average (about 1000 at the peak) since January this year. Unfortunately I don't have dedicated hardware available. On monday I will try to test it again using four cores instance on the server. As for your last question, I didn't do exact measuring, but from what I have noticed, the beam was doing some more work. Also, when they were on the separate machines, cpu load of the beam server was 2x higher than the stunnel one. Both combined were significantly smaller (about 10x) then the cpu load which occurred when they were on the same machine. The beam server code is very simple. Unfortunately I don't have it here right now, as I am posting this from my home, but I can post the code on Monday if necessary. > I remember a similar situation in the past trying to run load tests on > EC2. It was hard to get a predictable set of results when load testing > because the performance for the same test used to fluctuate. Yes, I also suspect it is hard to get the exact results on the cloud, which is why I originally mentioned I am using it. However, from the load tests I did couple of months ago, and from the current batch, I feel I can get approximation which is good enough. The tests seemed to work or fail consistently so far. > I cannot explain why it works better with stunnel. Do I have > to > manually configure ssl sessions when using erlang? As I > mentioned > earlier, the client does long polling i.e. it sends an > request, and as > soon as the request is responded, the new one is made. Is it > possible > that ssl handhsake occurs for every request? > > > I doubt the handshake occurs for every request. It might have > something to do with the fact that stunnel is written in C so is > likely to benefit in terms of performance. You could try hipe > compilation of the ssl application to see if that gives you any better > performance. Well it is the erlang client, and in fact, I'm using the ibrowse library and not httpc. There is no explicit ssl connection, but rather an infinite loop of https requests. At the client side, on what level is the SSL session being maintained: OS, erlang or the http(s) library? I will try to hipe compile it, thank you for the suggestion. Are there any instructions out there, which you could recommend, or should I google it myself? > > cheers > Chandru > Thank you again for taking the time to help me. Best regards, Sasa -------------- next part -------------- An HTML attachment was scrubbed... URL: From travis.jensen@REDACTED Sat May 7 01:12:46 2011 From: travis.jensen@REDACTED (Travis Jensen) Date: Fri, 6 May 2011 17:12:46 -0600 Subject: [erlang-questions] Building on OS X Message-ID: I'm having problems building 64-bit from source on OS X. I've tried a couple different things: *Without Hipe:* ./otp_build configure --enable-darwin-64bit --prefix=/Users/travis/opt/erlang --disable-hipe gcc -mdynamic-no-pic -m64 -g -O3 -fomit-frame-pointer -I/Users/travis/src2/foss/otp/erts/i386-apple-darwin10.7.0 -no-cpp-precomp -D_XOPEN_SOURCE -DERTS_SMP -DHAVE_CONFIG_H -Wall -Wstrict-prototypes -Wmissing-prototypes -Wdeclaration-after-statement -DUSE_THREADS -D_THREAD_SAFE -D_REENTRANT -DPOSIX_THREADS -Ii386-apple-darwin10.7.0/opt/smp -Ibeam -Isys/unix -Isys/common -Ii386-apple-darwin10.7.0 -Izlib -Ipcre -Ihipe -I../include -I../include/i386-apple-darwin10.7.0 -I../include/internal -I../include/internal/i386-apple-darwin10.7.0 -c beam/beam_emu.c -o obj/i386-apple-darwin10.7.0/opt/smp/beam_emu.o beam/beam_emu.c: In function 'process_main': beam/beam_emu.c:1177: error: label 'lb_hipe_trap_throw' used but not defined beam/beam_emu.c:1177: error: label 'lb_hipe_trap_return' used but not defined beam/beam_emu.c:1177: error: label 'lb_hipe_trap_resume' used but not defined beam/beam_emu.c:1177: error: label 'lb_hipe_trap_call_closure' used but not defined beam/beam_emu.c:1177: error: label 'lb_hipe_trap_call' used but not defined beam/beam_emu.c:1177: error: label 'lb_hipe_call_count' used but not defined make[3]: *** [obj/i386-apple-darwin10.7.0/opt/smp/beam_emu.o] Error 1 *With Hipe:* ./otp_build configure --enable-darwin-64bit --prefix=/Users/travis/opt/erlang gcc -mdynamic-no-pic -m64 -m64 -g -O3 -fomit-frame-pointer -I/Users/travis/src2/foss/otp/erts/i386-apple-darwin10.7.0 -no-cpp-precomp -D_XOPEN_SOURCE -DERTS_SMP -DHAVE_CONFIG_H -Wall -Wstrict-prototypes -Wmissing-prototypes -Wdeclaration-after-statement -DUSE_THREADS -D_THREAD_SAFE -D_REENTRANT -DPOSIX_THREADS -Ii386-apple-darwin10.7.0/opt/smp -Ibeam -Isys/unix -Isys/common -Ii386-apple-darwin10.7.0 -Izlib -Ipcre -Ihipe -I../include -I../include/i386-apple-darwin10.7.0 -I../include/internal -I../include/internal/i386-apple-darwin10.7.0 -c beam/erl_bif_info.c -o obj/i386-apple-darwin10.7.0/opt/smp/erl_bif_info.o beam/erl_bif_info.c: In function 'system_info_1': beam/erl_bif_info.c:2003: error: 'am_amd64' undeclared (first use in this function) beam/erl_bif_info.c:2003: error: (Each undeclared identifier is reported only once beam/erl_bif_info.c:2003: error: for each function it appears in.) I can build 32 bit fine, but I need 64 bit for couchdb. Any ideas? Thanks. tj -- *Travis Jensen* *** *Read the Software Maven @ http://softwaremaven.innerbrane.com/ Read my LinkedIn profile @ http://www.linkedin.com/in/travisjensen Read my Twitter mumblings @ http://twitter.com/SoftwareMaven Send me email @ travis.jensen@REDACTED **What kind of guy calls himself the Software Maven???** -------------- next part -------------- An HTML attachment was scrubbed... URL: From steven.charles.davis@REDACTED Sat May 7 03:25:31 2011 From: steven.charles.davis@REDACTED (Steve Davis) Date: Fri, 6 May 2011 18:25:31 -0700 (PDT) Subject: [erlang-questions] hmac sha256 erlang In-Reply-To: <199799912.152361304718224053.JavaMail.root@zimbra> References: <199799912.152361304718224053.JavaMail.root@zimbra> Message-ID: <16cacba8-0c40-4e3c-94d0-d3a1996245b2@a18g2000yqj.googlegroups.com> Maybe not but in this case it seems marginally faster and I can't see any other impact? I'm definitely open to correction/enlightenment, but I don't see why not here! /s On May 6, 4:43?pm, Robert Virding wrote: > Why would you want to do binary:copy here? It is not what it is intended for. > > Robert > > ----- "Steve Davis" wrote: > > > ...though now I would favor binary:copy instead of > > list_to_binary(lists:duplicate()), but that depends on what OTP > > version you have... > > > /s > > _______________________________________________ > > erlang-questions mailing list > > erlang-questi...@REDACTED > >http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions From barcojie@REDACTED Sat May 7 04:51:12 2011 From: barcojie@REDACTED (Barco You) Date: Sat, 7 May 2011 10:51:12 +0800 Subject: [erlang-questions] [Erlang-Q]How to configure Nitrogen webserver with http port 80 Message-ID: Dear All, After installing Nitrogen webserver and when startup it with "$nitrogen console", I can visit the localhost successfully with "http://localhost:8000", but I hope to use the default http port 80. When I edit the file /etc/inets_httpd.erleven as following, I got a crash error as below. Could you please instruct me how to change the port correctly? thanks! [ {port, 80}, {bind_address, {0,0,0,0}}, {server_name, "nitrogen"}, {server_root, "./"}, {document_root, "./site/static"}, {error_log, "./log/inets.log"}, {modules, [nitrogen_inets]}, {mime_types, [ {"css", "text/css"}, {"js", "text/javascript"}, {"html", "text/html"} ]} ]. =ERROR REPORT==== 7-May-2011::10:49:19 === Failed initiating web server: undefined {{listen,eacces}, {child,undefined, {httpd_acceptor,{0,0,0,0},80}, {httpd_acceptor,start_link, [<0.62.0>,ip_comm, {0,0,0,0}, 80,httpd_conf__0_0_0_0__80,15000]}, permanent,1000,worker, [httpd_acceptor]}} -------------- next part -------------- An HTML attachment was scrubbed... URL: From kennethstone@REDACTED Sat May 7 05:52:58 2011 From: kennethstone@REDACTED (Kenny Stone) Date: Fri, 6 May 2011 22:52:58 -0500 Subject: [erlang-questions] [Erlang-Q]How to configure Nitrogen webserver with http port 80 In-Reply-To: References: Message-ID: Are you running as root? Linux will usually make you have root permissions to run on 80. On Fri, May 6, 2011 at 9:51 PM, Barco You wrote: > Dear All, > > After installing Nitrogen webserver and when startup it with "$nitrogen > console", I can visit the localhost successfully with " > http://localhost:8000", but I hope to use the default http port 80. When I > edit the file /etc/inets_httpd.erleven as following, I got a crash error as > below. Could you please instruct me how to change the port correctly? > thanks! > > > [ > {port, 80}, > {bind_address, {0,0,0,0}}, > {server_name, "nitrogen"}, > {server_root, "./"}, > {document_root, "./site/static"}, > {error_log, "./log/inets.log"}, > {modules, [nitrogen_inets]}, > > {mime_types, [ > {"css", "text/css"}, > {"js", "text/javascript"}, > {"html", "text/html"} > ]} > ]. > > =ERROR REPORT==== 7-May-2011::10:49:19 === > Failed initiating web server: > undefined > {{listen,eacces}, > {child,undefined, > {httpd_acceptor,{0,0,0,0},80}, > {httpd_acceptor,start_link, > [<0.62.0>,ip_comm, > {0,0,0,0}, > 80,httpd_conf__0_0_0_0__80,15000]}, > permanent,1000,worker, > [httpd_acceptor]}} > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chandrashekhar.mullaparthi@REDACTED Sat May 7 07:49:46 2011 From: chandrashekhar.mullaparthi@REDACTED (Chandru) Date: Sat, 7 May 2011 06:49:46 +0100 Subject: [erlang-questions] mochiweb https/ssl In-Reply-To: <1304721239.1860.44.camel@sasa-laptop> References: <1304632965.1894.13.camel@sasa-laptop> <1304721239.1860.44.camel@sasa-laptop> Message-ID: Hi Sasa, On 6 May 2011 23:33, sasa wrote: > On Fri, 2011-05-06 at 21:30 +0100, Chandru wrote: > > I have then moved stunnel proxy to a separate server, and then it > worked perfectly. > > Currently, I am suspecting that cpu load might be the problem. When I > had stunnel on the same machine as erlang server, cpu load was going > high. The same thing happened when I used erlang ssl. When stunnel is > on a separate machine, the cpu load on both machines is fairly low. > > > That is quite strange. What is the spec of the machine? This might be a > peculiarity of the virtual instances you get on EC2. Is there any chance you > can repeat this test on dedicated hardware? When running both on the same > machine, have you monitored which process eats more CPU? beam or stunnel? > > > It is the "large" EC2 instance with two cores and 7.5 GB of memory. The > same type of instance sustained 12 hours of http load testing with 20 000 > clients and is running the production system serving about 700 http users on > average (about 1000 at the peak) since January this year. > Unfortunately I don't have dedicated hardware available. On monday I will > try to test it again using four cores instance on the server. > When you do this, try restricting the beam process to two cores and see if you get the same performance as using separate machines. You can do this using the '+S 2' option when starting the node. > I cannot explain why it works better with stunnel. Do I have to > manually configure ssl sessions when using erlang? As I mentioned > earlier, the client does long polling i.e. it sends an request, and as > soon as the request is responded, the new one is made. Is it possible > that ssl handhsake occurs for every request? > > > I doubt the handshake occurs for every request. It might have something to > do with the fact that stunnel is written in C so is likely to benefit in > terms of performance. You could try hipe compilation of the ssl application > to see if that gives you any better performance. > > > Well it is the erlang client, and in fact, I'm using the ibrowse library > and not httpc. There is no explicit ssl connection, but rather an infinite > loop of https requests. At the client side, on what level is the SSL session > being maintained: OS, erlang or the http(s) library? > ibrowse also uses the in built ssl application, so the SSL session is being maintained by the ssl application running within the beam process. I will try to hipe compile it, thank you for the suggestion. Are there any > instructions out there, which you could recommend, or should I google it > myself? > erl -man hipe :-) cheers Chandru -------------- next part -------------- An HTML attachment was scrubbed... URL: From yg@REDACTED Sat May 7 07:54:47 2011 From: yg@REDACTED (Yuri Ginsburg) Date: Fri, 6 May 2011 22:54:47 -0700 Subject: [erlang-questions] Building on OS X In-Reply-To: References: Message-ID: Travis, What version of OSX and gcc are you using. I have successfully built OTP for configuration: ./configure --enable-darwin-64bit --disable-hipe OSX version: Darwin mac 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23 18:28:53 PDT 2010; root:xnu-1504.7.4~1/RELEASE_I386 i386 gcc: gcc version 4.2.1 (Apple Inc. build 5664) --yg On Fri, May 6, 2011 at 4:12 PM, Travis Jensen wrote: > I'm having problems building 64-bit from source on OS X. I've tried a > couple different things: > > *Without Hipe:* ./otp_build configure --enable-darwin-64bit > --prefix=/Users/travis/opt/erlang --disable-hipe > > gcc -mdynamic-no-pic -m64 -g -O3 -fomit-frame-pointer > -I/Users/travis/src2/foss/otp/erts/i386-apple-darwin10.7.0 -no-cpp-precomp > -D_XOPEN_SOURCE -DERTS_SMP -DHAVE_CONFIG_H -Wall -Wstrict-prototypes > -Wmissing-prototypes -Wdeclaration-after-statement -DUSE_THREADS > -D_THREAD_SAFE -D_REENTRANT -DPOSIX_THREADS > -Ii386-apple-darwin10.7.0/opt/smp -Ibeam -Isys/unix -Isys/common > -Ii386-apple-darwin10.7.0 -Izlib -Ipcre -Ihipe -I../include > -I../include/i386-apple-darwin10.7.0 -I../include/internal > -I../include/internal/i386-apple-darwin10.7.0 -c beam/beam_emu.c -o > obj/i386-apple-darwin10.7.0/opt/smp/beam_emu.o > beam/beam_emu.c: In function 'process_main': > beam/beam_emu.c:1177: error: label 'lb_hipe_trap_throw' used but not > defined > beam/beam_emu.c:1177: error: label 'lb_hipe_trap_return' used but not > defined > beam/beam_emu.c:1177: error: label 'lb_hipe_trap_resume' used but not > defined > beam/beam_emu.c:1177: error: label 'lb_hipe_trap_call_closure' used but not > defined > beam/beam_emu.c:1177: error: label 'lb_hipe_trap_call' used but not defined > beam/beam_emu.c:1177: error: label 'lb_hipe_call_count' used but not > defined > make[3]: *** [obj/i386-apple-darwin10.7.0/opt/smp/beam_emu.o] Error 1 > > *With Hipe:* ./otp_build configure --enable-darwin-64bit > --prefix=/Users/travis/opt/erlang > > gcc -mdynamic-no-pic -m64 -m64 -g -O3 -fomit-frame-pointer > -I/Users/travis/src2/foss/otp/erts/i386-apple-darwin10.7.0 -no-cpp-precomp > -D_XOPEN_SOURCE -DERTS_SMP -DHAVE_CONFIG_H -Wall -Wstrict-prototypes > -Wmissing-prototypes -Wdeclaration-after-statement -DUSE_THREADS > -D_THREAD_SAFE -D_REENTRANT -DPOSIX_THREADS > -Ii386-apple-darwin10.7.0/opt/smp -Ibeam -Isys/unix -Isys/common > -Ii386-apple-darwin10.7.0 -Izlib -Ipcre -Ihipe -I../include > -I../include/i386-apple-darwin10.7.0 -I../include/internal > -I../include/internal/i386-apple-darwin10.7.0 -c beam/erl_bif_info.c -o > obj/i386-apple-darwin10.7.0/opt/smp/erl_bif_info.o > beam/erl_bif_info.c: In function 'system_info_1': > beam/erl_bif_info.c:2003: error: 'am_amd64' undeclared (first use in this > function) > beam/erl_bif_info.c:2003: error: (Each undeclared identifier is reported > only once > beam/erl_bif_info.c:2003: error: for each function it appears in.) > > I can build 32 bit fine, but I need 64 bit for couchdb. Any ideas? > > Thanks. > > tj > -- > *Travis Jensen* > *** > *Read the Software Maven @ http://softwaremaven.innerbrane.com/ > Read my LinkedIn profile @ http://www.linkedin.com/in/travisjensen > Read my Twitter mumblings @ http://twitter.com/SoftwareMaven > Send me email @ travis.jensen@REDACTED > > **What kind of guy calls himself the Software Maven???** > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Sat May 7 10:38:29 2011 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Sat, 07 May 2011 10:38:29 +0200 Subject: [erlang-questions] [Erlang-Q]How to configure Nitrogen webserver with http port 80 In-Reply-To: References: Message-ID: <4DC50505.7000902@dev-extend.eu> Hello, On 05/07/2011 04:51 AM, Barco You wrote: > After installing Nitrogen webserver and when startup it with "$nitrogen > console", I can visit the localhost successfully with > "http://localhost:8000", but I hope to use the default http port 80. > When I edit the file /etc/inets_httpd.erleven as following, I got a > crash error as below. Could you please instruct me how to change the > port correctly? thanks! Only root can open ports <= 1024. Problem is, it's not safe to run Erlang as root. There's two solutions to solve this: * Setup a reverse proxy in cherokee or nginx to your port 8000. * Use procket: https://github.com/msantos/procket Considering you are using Nitrogen you should take the first option, unless you're willing to patch Nitrogen. -- Lo?c Hoguin Dev:Extend From jameschurchman@REDACTED Sat May 7 12:09:27 2011 From: jameschurchman@REDACTED (James Churchman) Date: Sat, 7 May 2011 11:09:27 +0100 Subject: [erlang-questions] spdy in mouchi web Message-ID: Hi Guys, google developed a http replacement / improvement called SPDY (pronounced "SPeeDY" :-) ) Its now active in chrome : ( link to the unfortunately purchased then shutdown by aol blog : downloadsquad ) http://downloadsquad.switched.com/2011/04/11/google-chrome-now-uses-spdy-http-replacement-halves-page-load-t/ and here is googles info about it : http://www.chromium.org/spdy/spdy-whitepaper One question that might be most common that it answers : *Q: Is SPDY a replacement for HTTP?* * * *A: No. SPDY replaces some parts of HTTP, but mostly augments it. At the highest level of the application layer, the request-response protocol remains the same. SPDY still uses HTTP methods, headers, and other semantics. But SPDY overrides other parts of the protocol, such as connection management and data transfer formats.* So my question is ( might be quid a huge ask), is, does anybody plan to add this to mouciweb ( and therefore webmachine ) I am guessing its a bit of a chicken/egg seniario but if it has google behind it that may help adoption, and it may bring dev's to erlang if its (one of) the first to support it! It might also improve rest applications ( like riak ) in the future too If not then hopefully a few more people are now aware of its existence after this email :-) James -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf.wiger@REDACTED Sat May 7 13:17:35 2011 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Sat, 7 May 2011 13:17:35 +0200 Subject: [erlang-questions] spdy in mouchi web In-Reply-To: References: Message-ID: <9C237C78-5B6D-44FE-8A7D-711C74D6C8A7@erlang-solutions.com> Interesting. As SPDY sits on top of SSL, one might also note that Erlang's (new) SSL implementation is unusually scalable - not everyone who wants to run a web server will be happy to put an SSL offload accelerator in front of it? But reading further, the current version of SPDY uses TCP instead. Some of the concepts remind me of an experiment I made called VCC (http://svn.ulf.wiger.net/vcc/trunk/vcc), which also implemented "streams" on top of VCC (although I called them "virtual channels", corrupted by years of work in ATM networking design). I incorporated Erlang notions like monitoring channels, and also "spawning" temporary channels based on a "template", and close-on-reply (which SPDY also has a version of). But the main reason for my experiment was to support version negotiation between peer nodes, together with side-effect-free version transformers, in order to handle redundancy upgrades in large Erlang systems. Perhaps the SPDY ideas of uni-directional streams and re-prioritization of streams could hold some promise also for erlang-to-erlang communication? Currently, Distributed Erlang has no means of prioritizing things like net_kernel ping messages... BR, Ulf W On 7 May 2011, at 12:09, James Churchman wrote: > So my question is ( might be quid a huge ask), is, does anybody plan to add this to mouciweb ( and therefore webmachine ) > Ulf Wiger, CTO, Erlang Solutions, Ltd. http://erlang-solutions.com From ulf.wiger@REDACTED Sat May 7 13:19:40 2011 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Sat, 7 May 2011 13:19:40 +0200 Subject: [erlang-questions] spdy in mouchi web In-Reply-To: <9C237C78-5B6D-44FE-8A7D-711C74D6C8A7@erlang-solutions.com> References: <9C237C78-5B6D-44FE-8A7D-711C74D6C8A7@erlang-solutions.com> Message-ID: On 7 May 2011, at 13:17, Ulf Wiger wrote: > VCC (http://svn.ulf.wiger.net/vcc/trunk/vcc), which also implemented "streams" on top of VCC ?should of course have been "streams" on top of TCP. BR, Ulf W Ulf Wiger, CTO, Erlang Solutions, Ltd. http://erlang-solutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Sat May 7 14:13:58 2011 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Sat, 07 May 2011 14:13:58 +0200 Subject: [erlang-questions] spdy in mouchi web In-Reply-To: References: Message-ID: <4DC53786.7090804@dev-extend.eu> On 05/07/2011 12:09 PM, James Churchman wrote: > So my question is ( might be quid a huge ask), is, does anybody plan to > add this to mouciweb ( and therefore webmachine ) > > I am guessing its a bit of a chicken/egg seniario but if it has google > behind it that may help adoption, and it may bring dev's to erlang if > its (one of) the first to support it! It'll become interesting whenever the protocol becomes stable and whenever they allow Chrome to use it outside the Google services, as it's apparently hardcoded for everything else currently. It is an interesting experiment as it allows processing multiple requests in parallel over a single TCP connection. However, for most applications it doesn't give much advantage over pipelining so its adoption in other browsers might take a while. Still this is interesting enough to support it whenever we can actually use it, in my opinion. -- Lo?c Hoguin Dev:Extend From jameschurchman@REDACTED Sat May 7 15:21:51 2011 From: jameschurchman@REDACTED (James Churchman) Date: Sat, 7 May 2011 14:21:51 +0100 Subject: [erlang-questions] spdy in mouchi web In-Reply-To: <9C237C78-5B6D-44FE-8A7D-711C74D6C8A7@erlang-solutions.com> References: <9C237C78-5B6D-44FE-8A7D-711C74D6C8A7@erlang-solutions.com> Message-ID: >Some of the concepts remind me of an experiment I made called VCC ( http://svn.ulf.wiger.net/vcc/trunk/vcc), which >also implemented "streams" on top of VCC (although I called them "virtual channels", corrupted by years of work in >ATM networking design). I incorporated Erlang notions like monitoring channels, and also "spawning" temporary >channels based on a "template", and close-on-reply (which SPDY also has a version of). as usual erlang / erlangers are years ahead with ideas over the general status quo :-) >Distributed Erlang has no means of prioritizing things like net_kernel ping messages... not the kindof aplication i was thinking of but you woudl know more than me Ulf :-) >It'll become interesting whenever the protocol becomes stable and >whenever they allow Chrome to use it outside the Google services, >it's apparently hardcoded for everything else currently. i did not know this but it sounds sensible... if it was widely implemented then proved to have some fatal problem, google can work this out by testing it its self on quite a good use case like gmail, then fixing it ( websockets anyone ? ) im sure if the experiment is successful, even if there was a minor modification then google would open it up to all > ( it doesn't give much advantage over pipelining ) are you sure it does not give much? and for the kind of web-apps built in erlang might benifit most! > so its adoption in other browsers might take a while. browser makers are totaly obsessed with sub microsecond benchmarks ( even if they don't effect the end user much along with css selectors that no-one ever uses ) so i think it would be implemented in firefox very fast... maybe not IE, but most users on IE are not as discriminating users! On 7 May 2011 13:13, Lo?c Hoguin wrote: > On 05/07/2011 12:09 PM, James Churchman wrote: > > So my question is ( might be quid a huge ask), is, does anybody plan to > > add this to mouciweb ( and therefore webmachine ) > > > > I am guessing its a bit of a chicken/egg seniario but if it has google > > behind it that may help adoption, and it may bring dev's to erlang if > > its (one of) the first to support it! > > It'll become interesting whenever the protocol becomes stable and > whenever they allow Chrome to use it outside the Google services, as > it's apparently hardcoded for everything else currently. > > It is an interesting experiment as it allows processing multiple > requests in parallel over a single TCP connection. However, for most > applications it doesn't give much advantage over pipelining so its > adoption in other browsers might take a while. > > Still this is interesting enough to support it whenever we can actually > use it, in my opinion. > > -- > Lo?c Hoguin > Dev:Extend > On 7 May 2011 12:17, Ulf Wiger wrote: > > Interesting. > > As SPDY sits on top of SSL, one might also note that Erlang's (new) SSL > implementation is unusually scalable - not everyone who wants to run a web > server will be happy to put an SSL offload accelerator in front of it? > > But reading further, the current version of SPDY uses TCP instead. > > Some of the concepts remind me of an experiment I made called VCC ( > http://svn.ulf.wiger.net/vcc/trunk/vcc), which also implemented "streams" > on top of VCC (although I called them "virtual channels", corrupted by years > of work in ATM networking design). I incorporated Erlang notions like > monitoring channels, and also "spawning" temporary channels based on a > "template", and close-on-reply (which SPDY also has a version of). > > But the main reason for my experiment was to support version negotiation > between peer nodes, together with side-effect-free version transformers, in > order to handle redundancy upgrades in large Erlang systems. > > Perhaps the SPDY ideas of uni-directional streams and re-prioritization of > streams could hold some promise also for erlang-to-erlang communication? > Currently, Distributed Erlang has no means of prioritizing things like > net_kernel ping messages... > > BR, > Ulf W > > On 7 May 2011, at 12:09, James Churchman wrote: > > > So my question is ( might be quid a huge ask), is, does anybody plan to > add this to mouciweb ( and therefore webmachine ) > > > > Ulf Wiger, CTO, Erlang Solutions, Ltd. > http://erlang-solutions.com > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jack@REDACTED Sat May 7 15:27:02 2011 From: jack@REDACTED (Jack Moffitt) Date: Sat, 7 May 2011 07:27:02 -0600 Subject: [erlang-questions] spdy in mouchi web In-Reply-To: References: <9C237C78-5B6D-44FE-8A7D-711C74D6C8A7@erlang-solutions.com> Message-ID: >> ( it doesn't give much advantage over pipelining ) > are you sure it does not give much? and for the kind of web-apps built in > erlang might benifit most! I'm pretty sure the SPDY guys on the websocket list said that most of the benefit came from the HTTP header compression. Also sending data compression in a POST (which is something that HTTP supports but browsers don't seem to implement) would make most long polling applications much more bandwidth efficient. And it probably has sane error detection, which would make the code on the client side much simpler than the stuff we currently used filled with timeout detections and workarounds. jack. From vinoski@REDACTED Sat May 7 16:16:24 2011 From: vinoski@REDACTED (Steve Vinoski) Date: Sat, 7 May 2011 10:16:24 -0400 Subject: [erlang-questions] Yaws, now with rebar support Message-ID: Thanks to a foundation of work established by Tuncer Ayaz, today I was able to complete changes required to enable the Yaws web server to be built with rebar. I just pushed those changes to the Yaws github repo: https://github.com/klacke/yaws Thanks Tuncer! --steve From sigmastar@REDACTED Sat May 7 18:05:48 2011 From: sigmastar@REDACTED (Jesse Gumm) Date: Sat, 7 May 2011 11:05:48 -0500 Subject: [erlang-questions] [Erlang-Q]How to configure Nitrogen webserver with http port 80 In-Reply-To: <4DC50505.7000902@dev-extend.eu> References: <4DC50505.7000902@dev-extend.eu> Message-ID: There is a third option that will allow you to bind a privileged port (this is not specific to Erlang): setcap sudo setcap cap_net_bind_service+ep ./erts-X.Y.Z/bin/beam sudo setcap cap_net_bind_service+ep ./erts-X.Y.Z/bin/beam.smp This command will give the target binary the ability to bind privileged ports regardless of the user, so it's a bit dangerous in a multi-user environment, but if you're the only user on the machine, go for it. That said, I recommend using nginx anyway. -Jesse On Sat, May 7, 2011 at 3:38 AM, Lo?c Hoguin wrote: > Hello, > > On 05/07/2011 04:51 AM, Barco You wrote: >> After installing Nitrogen webserver and when startup it with "$nitrogen >> console", I can visit the localhost successfully with >> "http://localhost:8000", but I hope to use the default http port 80. >> When I edit the file /etc/inets_httpd.erleven as following, I got a >> crash error as below. Could you please instruct me how to change the >> port correctly? thanks! > > Only root can open ports <= 1024. Problem is, it's not safe to run > Erlang as root. There's two solutions to solve this: > > * Setup a reverse proxy in cherokee or nginx to your port 8000. > * Use procket: https://github.com/msantos/procket > > Considering you are using Nitrogen you should take the first option, > unless you're willing to patch Nitrogen. > > -- > Lo?c Hoguin > Dev:Extend > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Jesse Gumm Sigma Star Systems 414.940.4866 gumm@REDACTED http://www.sigma-star.com From steven.payne@REDACTED Sat May 7 19:34:33 2011 From: steven.payne@REDACTED (Steven Payne) Date: Sat, 7 May 2011 13:34:33 -0400 Subject: [erlang-questions] (no subject) Message-ID: <6577600CA01B49F1BACCC4723B086DB7@StevePC> An HTML attachment was scrubbed... URL: From zvi.avraham@REDACTED Sat May 7 19:46:18 2011 From: zvi.avraham@REDACTED (Zvi) Date: Sat, 7 May 2011 10:46:18 -0700 (PDT) Subject: [erlang-questions] What's the best way of producing bitmaps/pixelmaps through Erlang. In-Reply-To: References: Message-ID: <39be0c60-0105-4b1e-bda3-e197325f0edb@e35g2000yqc.googlegroups.com> The only one open-source I know is erl_img from jungerl: https://github.com/gebi/jungerl/tree/master/lib/erl_img Also look on github for erl_img for varoius forks. See the docs here: http://doc.erlagner.org/index.html?i=0&search=erl_img#erl_img At the end we wrote our own image file format in erlang. On May 5, 2:27?am, "G.S." wrote: > Hello, > > What's the best way to produce/specify bitmaps/pixemaps using Erlang? Is > anyone using particular modules, or projects for this? > > Thanks, > -Gene > > _______________________________________________ > erlang-questions mailing list > erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions From vances@REDACTED Sat May 7 19:56:31 2011 From: vances@REDACTED (Vance Shipley) Date: Sat, 7 May 2011 13:56:31 -0400 Subject: [erlang-questions] What's the best way of producing bitmaps/pixelmaps through Erlang. In-Reply-To: <39be0c60-0105-4b1e-bda3-e197325f0edb@e35g2000yqc.googlegroups.com> References: <39be0c60-0105-4b1e-bda3-e197325f0edb@e35g2000yqc.googlegroups.com> Message-ID: <20110507175631.GB305@h216-235-12-168.host.egate.net> Have you looked at egd? http://www.erlang.org/doc/man/egd.html On May 5, 2:27?am, "G.S." wrote: } What's the best way to produce/specify bitmaps/pixemaps using Erlang? Is } anyone using particular modules, or projects for this? -- -Vance From corticalcomputer@REDACTED Sat May 7 21:39:33 2011 From: corticalcomputer@REDACTED (G.S.) Date: Sat, 7 May 2011 12:39:33 -0700 Subject: [erlang-questions] What's the best way of producing bitmaps/pixelmaps through Erlang. In-Reply-To: <20110507175631.GB305@h216-235-12-168.host.egate.net> References: <39be0c60-0105-4b1e-bda3-e197325f0edb@e35g2000yqc.googlegroups.com> <20110507175631.GB305@h216-235-12-168.host.egate.net> Message-ID: Thanks, I will check both. By the way, the purpose of use is creating Fractal Art. Regards, -Gene On Sat, May 7, 2011 at 10:56 AM, Vance Shipley wrote: > Have you looked at egd? > > http://www.erlang.org/doc/man/egd.html > > On May 5, 2:27 am, "G.S." wrote: > } What's the best way to produce/specify bitmaps/pixemaps using Erlang? Is > } anyone using particular modules, or projects for this? > > -- > -Vance > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vances@REDACTED Sat May 7 21:48:28 2011 From: vances@REDACTED (Vance Shipley) Date: Sat, 7 May 2011 15:48:28 -0400 Subject: [erlang-questions] What's the best way of producing bitmaps/pixelmaps through Erlang. In-Reply-To: References: <39be0c60-0105-4b1e-bda3-e197325f0edb@e35g2000yqc.googlegroups.com> <20110507175631.GB305@h216-235-12-168.host.egate.net> Message-ID: <20110507194827.GE305@h216-235-12-168.host.egate.net> On Sat, May 07, 2011 at 12:39:33PM -0700, G.S. wrote: } By the way, the purpose of use is creating Fractal Art. In that case you may want to look at this: lib/erlang/lib/gs-1.5.13/contribs/mandel -- -Vance From steven.charles.davis@REDACTED Sun May 8 03:52:19 2011 From: steven.charles.davis@REDACTED (Steve Davis) Date: Sat, 7 May 2011 18:52:19 -0700 (PDT) Subject: [erlang-questions] What's the best way of producing bitmaps/pixelmaps through Erlang. In-Reply-To: References: <39be0c60-0105-4b1e-bda3-e197325f0edb@e35g2000yqc.googlegroups.com> <20110507175631.GB305@h216-235-12-168.host.egate.net> Message-ID: <51066b70-8a07-4d2f-aee0-73aba951195f@q32g2000yqn.googlegroups.com> Hi, My personal take on this is that you should process the fractal algorithm in a way that's separated from any particular file format, building the image in a very generic way; e.g. perhaps using a record like -record(image, {id, width, height, pixel_depth, rgba = []}). where rgba are the generated 4-tuples {R, G, B, A} representing the data points. Then you could write transcoders (codecs) from this format to any number of binary image file formats. The binary syntax of Erlang will then prove its worth in spades. It's somewhat curious to me that a comprehensive library for image codecs hasn't emerged already, given the ease of which this can be done in Erlang's binary/bit syntax. HTH, Steve On May 7, 2:39?pm, "G.S." wrote: > Thanks, I will check both. > > By the way, the purpose of use is creating Fractal Art. > > Regards, > -Gene > > > > > > > > On Sat, May 7, 2011 at 10:56 AM, Vance Shipley wrote: > > Have you looked at egd? > > > ? ? ? ?http://www.erlang.org/doc/man/egd.html > > > On May 5, 2:27 am, "G.S." wrote: > > } ?What's the best way to produce/specify bitmaps/pixemaps using Erlang? Is > > } ?anyone using particular modules, or projects for this? > > > -- > > ? ? ? ? -Vance > > _______________________________________________ > > erlang-questions mailing list > > erlang-questi...@REDACTED > >http://erlang.org/mailman/listinfo/erlang-questions > > > > _______________________________________________ > erlang-questions mailing list > erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions From steven.charles.davis@REDACTED Sun May 8 04:04:11 2011 From: steven.charles.davis@REDACTED (Steve Davis) Date: Sat, 7 May 2011 19:04:11 -0700 (PDT) Subject: [erlang-questions] What's the best way of producing bitmaps/pixelmaps through Erlang. In-Reply-To: <51066b70-8a07-4d2f-aee0-73aba951195f@q32g2000yqn.googlegroups.com> References: <39be0c60-0105-4b1e-bda3-e197325f0edb@e35g2000yqc.googlegroups.com> <20110507175631.GB305@h216-235-12-168.host.egate.net> <51066b70-8a07-4d2f-aee0-73aba951195f@q32g2000yqn.googlegroups.com> Message-ID: <75c8986f-1f54-4834-9e66-ac537605bb86@v10g2000yqn.googlegroups.com> More concretely as an example, a TGA format binary could be created as simply as this: encode(#image{id = undefined}) -> encode(#image{id = <<>>}); encode(#image{id = ID, width = W, height = H, pixel_depth = BPP, rgba = L}) -> Header = <<(byte_size(ID)), 0, 2, 0:40, 0:16, 0:16, W:16/little, H:16/ little, BPP, 0:2, 2:2, 0:4, ID/binary>>, Data = encode(L, <<>>), Trailer = <<0:64, "TRUEVISION-XFILE.", 0>>, <
>. encode([{R, G, B, A}|T], Bin) -> encode(T, <>); encode([], Bin) -> Bin. From steven.charles.davis@REDACTED Sun May 8 04:18:17 2011 From: steven.charles.davis@REDACTED (Steve Davis) Date: Sat, 7 May 2011 19:18:17 -0700 (PDT) Subject: [erlang-questions] [Erlang-Q]How to configure Nitrogen webserver with http port 80 In-Reply-To: References: <4DC50505.7000902@dev-extend.eu> Message-ID: <50d82ea5-d5af-4abe-8a3b-f645e3041f97@y12g2000yqh.googlegroups.com> If you have admin skills, I'm thinking IPTables is the most direct answer. If you have time to learn then LHN has a good practical reference: http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch14_:_Linux_Firewalls_Using_iptables /s From thomasl_erlang@REDACTED Sun May 8 12:38:07 2011 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Sun, 8 May 2011 03:38:07 -0700 (PDT) Subject: [erlang-questions] [Erlang-Q]How to configure Nitrogen webserver with http port 80 In-Reply-To: <4DC50505.7000902@dev-extend.eu> References: <4DC50505.7000902@dev-extend.eu> Message-ID: <145461.96445.qm@web111404.mail.gq1.yahoo.com> >________________________________ >From: Lo?c Hoguin >To: Barco You > >Only root can open ports <= 1024. Problem is, it's not safe to run >Erlang as root. There's two solutions to solve this: > >* Setup a reverse proxy in cherokee or nginx to your port 8000. >* Use procket: https://github.com/msantos/procket > >Considering you are using Nitrogen you should take the first option, >unless you're willing to patch Nitrogen. Procket looks very interesting, anyone use it? For more options, yaws has a longish discussion: http://yaws.hyber.org/privbind.yaws By the way, to provide some concrete data, we go with the reverse proxy approach (haproxy in our case). In a real service, you will probably want something like that to manage load balancing and failover anyway. Best, Thomas From jan@REDACTED Sun May 8 18:35:06 2011 From: jan@REDACTED (Jan Lehnardt) Date: Sun, 8 May 2011 18:35:06 +0200 Subject: [erlang-questions] Using CouchDB to hold state for FSM - pros and cons? In-Reply-To: References: Message-ID: <06EBF27E-FB12-4F12-8DEE-9B7624E26564@apache.org> On 2 May 2011, at 09:52, Joe Armstrong wrote: > CouchDb will store all the data forever, which is probably not what you want. Scalaris or Riak > sounds like a better fit. CouchDB is well capable of deleting data if you ask it to :) I agree with the other comments Joe and Ulf made, though. Cheers Jan -- > > /Joe > > > On Mon, May 2, 2011 at 8:56 AM, David Mitchell wrote: > Hi all, > > I've got to build an enormous finite state machine (FSM) to hold state for tens of thousands of in-flight transactions. The various state transitions aren't well known yet; all I know is there's going to be lots of state transactions per transaction, transaction volume will be extremely high, and I'll probably have a bare minimum of time to throw together a working solution ;-> > > In the past I've used mnesia to hold transaction state for similar projects, but I've read a few articles about problems with it scaling and have a bit of a concern on that count for this particular project. I've been using CouchDB for a few unrelated projects recently, and have been impressed with it on every score - on the surface it seems to be a good fit for my specific problem. However I haven't stumbled on anybody using CouchDB as a high throughput, transitional data store - everything I've read about it has involved CouchDB working more or less as a NoSQL version of a "traditional" write-once, read-often data store. > > My application is far more "write-once, update-many-times-very-quickly, delete" from a data perspective. > > Has anyone used CouchDB as a FSM data store in a similar project in the past? Pros and cons? Any tips or suggestions? > > Thanks in advance > > David Mitchell > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From mjtruog@REDACTED Sun May 8 21:37:10 2011 From: mjtruog@REDACTED (Michael Truog) Date: Sun, 08 May 2011 12:37:10 -0700 Subject: [erlang-questions] Erlounge SF/Bay: 7:30 tonight (5/5) in SOMA In-Reply-To: <4DC313F1.9050504@props.org> References: <4DC313F1.9050504@props.org> Message-ID: <4DC6F0E6.1090703@gmail.com> For those of you that were unable to be in San Francisco for the ErLounge but wanted to see the CloudI presentation, the presentation can be viewed here: http://cloudi.org/docs/cloudi_erlounge_sfbay2011.pdf For more information, see the FAQ here: http://cloudi.org/faq.html On 05/05/2011 02:17 PM, Christian Westbrook wrote: > Just a reminder to all who may be in the San Francisco bay area -- you are invited to: > > -=- Keep Your Head Out of the Cloud with Erlang -=- > > Join us this evening for a special ErLounge. We've the honor of being joined by two very brave guest speakers: > > * Patrick Sullivan (of 2600, our generous host) > will share their experiences using erlang in VoIP > > * Michael Truog, creator of the CloudI framework (cloudi.org) > has the low-down on latest developments on CloudI > ( and if we can coerce him, perhaps even a demo! ;) ) > > time: 7:30pm > > location: 2600 Headquarters (SOMA) > > 116 Natoma Street, 2nd floor > > SF, CA 94105 > > Street parking is available; public transit always works. > > > For more info or to RSVP: meetup.com/ErLounge > > > See you tonight, > Christian > > > > Christian Westbrook > Erlanguatan, CoTweet > cw@REDACTED / cw@REDACTED / @cdubs > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From robert.virding@REDACTED Sun May 8 23:42:59 2011 From: robert.virding@REDACTED (Robert Virding) Date: Sun, 8 May 2011 21:42:59 +0000 (GMT) Subject: [erlang-questions] hmac sha256 erlang In-Reply-To: <16cacba8-0c40-4e3c-94d0-d3a1996245b2@a18g2000yqj.googlegroups.com> Message-ID: <879346087.152711304890979473.JavaMail.root@zimbra> In the docs for binary:copy it says: "This function will always create a new binary, even if N = 1. By using copy/1 on a binary referencing a larger binary, one might free up the larger binary for garbage collection." Although there is a caveat saying that it might be actually useful in special cases. Robert ----- "Steve Davis" wrote: > Maybe not but in this case it seems marginally faster and I can't see > any other impact? > > I'm definitely open to correction/enlightenment, but I don't see why > not here! > > /s > > On May 6, 4:43?pm, Robert Virding solutions.com> wrote: > > Why would you want to do binary:copy here? It is not what it is > intended for. > > > > Robert > > > > ----- "Steve Davis" wrote: > > > > > ...though now I would favor binary:copy instead of > > > list_to_binary(lists:duplicate()), but that depends on what OTP > > > version you have... > > > > > /s > > > _______________________________________________ > > > erlang-questions mailing list > > > erlang-questi...@REDACTED > > >http://erlang.org/mailman/listinfo/erlang-questions > > > > _______________________________________________ > > erlang-questions mailing list > > > erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From bob@REDACTED Sun May 8 23:49:25 2011 From: bob@REDACTED (Bob Ippolito) Date: Sun, 8 May 2011 15:49:25 -0600 Subject: [erlang-questions] hmac sha256 erlang In-Reply-To: <879346087.152711304890979473.JavaMail.root@zimbra> References: <16cacba8-0c40-4e3c-94d0-d3a1996245b2@a18g2000yqj.googlegroups.com> <879346087.152711304890979473.JavaMail.root@zimbra> Message-ID: binary:copy/2 is more useful for this purpose. On Sunday, May 8, 2011, Robert Virding wrote: > In the docs for binary:copy it says: > > "This function will always create a new binary, even if N = 1. By using copy/1 on a binary referencing a larger binary, one might free up the larger binary for garbage collection." > > Although there is a caveat saying that it might be actually useful in special cases. > > Robert > > ----- "Steve Davis" wrote: > >> Maybe not but in this case it seems marginally faster and I can't see >> any other impact? >> >> I'm definitely open to correction/enlightenment, but I don't see why >> not here! >> >> /s >> >> On May 6, 4:43?pm, Robert Virding > solutions.com> wrote: >> > Why would you want to do binary:copy here? It is not what it is >> intended for. >> > >> > Robert >> > >> > ----- "Steve Davis" wrote: >> > >> > > ...though now I would favor binary:copy instead of >> > > list_to_binary(lists:duplicate()), but that depends on what OTP >> > > version you have... >> > >> > > /s >> > > _______________________________________________ >> > > erlang-questions mailing list >> > > erlang-questi...@REDACTED >> > >http://erlang.org/mailman/listinfo/erlang-questions >> > >> > _______________________________________________ >> > erlang-questions mailing list >> > >> erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From steven.charles.davis@REDACTED Mon May 9 00:19:40 2011 From: steven.charles.davis@REDACTED (Steve Davis) Date: Sun, 08 May 2011 17:19:40 -0500 Subject: [erlang-questions] hmac sha256 erlang In-Reply-To: References: <16cacba8-0c40-4e3c-94d0-d3a1996245b2@a18g2000yqj.googlegroups.com> <879346087.152711304890979473.JavaMail.root@zimbra> Message-ID: <4DC716FC.6060209@gmail.com> I had RTFM before making that suggestion! However, with my interest mildly piqued by this, I checked a little further, adding a "manual append" comparison just for good measure: test(Num) -> T0 = funtime(fun lcopy/0, Num), T1 = funtime(fun bcopy/0, Num), T2 = funtime(fun ccopy/0, Num), {T0, T1, T2}. lcopy() -> list_to_binary(lists:duplicate(128, 16#36)). bcopy() -> binary:copy(<<16#36>>, 128). ccopy() -> ccopy(<<16#36>>, 128). ccopy(Bin, Count) when Count > 0 -> ccopy(<>, Count - 1); ccopy(Bin, 0) -> Bin. funtime(F, Repeats) -> {A1, B1, C1} = erlang:now(), exec_fun(F, Repeats), {A2, B2, C2} = erlang:now(), ((A2-A1) * 1000000 + (B2-B1)) * 1000 + (C2-C1) / 1000. exec_fun(_, 0) -> ok; exec_fun(F, Count) -> F(), exec_fun(F, Count - 1). 1> copier:test(10000). {265.0,62.999,280.999} Not really any kind of formal test but it does seem to confirm the choice/advice. /s On 5/8/2011 4:49 PM, Bob Ippolito wrote: > binary:copy/2 is more useful for this purpose. > > On Sunday, May 8, 2011, Robert Virding > wrote: >> In the docs for binary:copy it says: >> >> "This function will always create a new binary, even if N = 1. By using copy/1 on a binary referencing a larger binary, one might free up the larger binary for garbage collection." >> >> Although there is a caveat saying that it might be actually useful in special cases. >> >> Robert >> >> ----- "Steve Davis" wrote: >> >>> Maybe not but in this case it seems marginally faster and I can't see >>> any other impact? >>> >>> I'm definitely open to correction/enlightenment, but I don't see why >>> not here! >>> >>> /s >>> >>> On May 6, 4:43 pm, Robert Virding>> solutions.com> wrote: >>>> Why would you want to do binary:copy here? It is not what it is >>> intended for. >>>> >>>> Robert >>>> >>>> ----- "Steve Davis" wrote: >>>> >>>>> ...though now I would favor binary:copy instead of >>>>> list_to_binary(lists:duplicate()), but that depends on what OTP >>>>> version you have... >>>> >>>>> /s >> > From vasdeveloper@REDACTED Mon May 9 03:17:09 2011 From: vasdeveloper@REDACTED (Kannan) Date: Mon, 9 May 2011 06:47:09 +0530 Subject: [erlang-questions] gen_sctp Message-ID: Hi List, One would ever want to handle a "connection" in TCP or an "association" in SCTP with a dedicated worker process, from the server point of view. It is made possible by separating listening socket and data sockets in TCP. One will spawn a worker for each data socket and give the control of that socket to the worker. This is not possible in SCTP as there is no separation of sockets as such. Now the problem is how to handle each association with a separate worker process? The workaround I can think is, keeping the controlling process as the message clearing process with a dedicated worker process for each association. Any suggestions? Best, Kannan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Mon May 9 05:45:41 2011 From: ok@REDACTED (Richard O'Keefe) Date: Mon, 9 May 2011 15:45:41 +1200 Subject: [erlang-questions] byte() vs. char() use in documentation In-Reply-To: <60C82374-90CF-4200-9F87-1B662173A4B1@masklinn.net> References: <20110502091415.GA6512@erix.ericsson.se> <20110503094549.GA10981@erix.ericsson.se> <201105040533.58985.als@iinet.net.au> <20110504075734.GA16456@erix.ericsson.se> <294BF31C-A04F-49C1-8CCB-E168D5AFAE5B@cs.otago.ac.nz> <60C82374-90CF-4200-9F87-1B662173A4B1@masklinn.net> Message-ID: <0E4AB3DB-3830-40C8-BA3F-7AACF548C6F5@cs.otago.ac.nz> On 6/05/2011, at 6:49 PM, Masklinn wrote: > On 2011-05-06, at 07:34 , Richard O'Keefe wrote: >>> To come back to the point, we have to define what we mean with the Erlang >>> char() type: >>> - if it's an individual character then it can naturally be represented as >>> a single integer for its code point >>> - if it's a logical character then it has to be a list of integers >> Since we cannot know what a logical character is, and since we need *some* >> representation of Unicode code points, I recommend that char()=code point. > Why pick code points rather than grapheme cluster? For so many many reasons I haven't the patience to list them all. A. Because it is the simplest thing that could possibly work. B. Because grapheme clusters aren't any better a fit to the user's perception of a "character" than code points. C. Because Unicode properties are defined for characters, not grapheme clusters. D. Because there is a finite and not *hopelessly* large set of code points, but the set of grapheme clusters is unbounded ... > >>> In any case, the language must provide specific functions to work on strings >>> and characters. For instance, a logical character comparison must take into >>> account the Unicode equivalence. >> What do you mean "THE" equivalence?\ > I would guess he means what he linked: unicode equivalence (as per unicode), > likely compatible (in order to equate "?" with "ffi" for instance) Yes, but there are *several* notions of equivalence in the Unicode standard, which was my point. Which of them is "THE" equivalence? (The one with arguably the strongest claim does NOT deal with compatibility mappings.) From ok@REDACTED Mon May 9 05:49:13 2011 From: ok@REDACTED (Richard O'Keefe) Date: Mon, 9 May 2011 15:49:13 +1200 Subject: [erlang-questions] byte() vs. char() use in documentation In-Reply-To: <19907.40326.311605.693467@mail.cern.ch> References: <20110502091415.GA6512@erix.ericsson.se> <20110503094549.GA10981@erix.ericsson.se> <201105040533.58985.als@iinet.net.au> <20110504075734.GA16456@erix.ericsson.se> <294BF31C-A04F-49C1-8CCB-E168D5AFAE5B@cs.otago.ac.nz> <19907.40326.311605.693467@mail.cern.ch> Message-ID: <835E778D-B273-442F-BBEC-F2FBC8228512@cs.otago.ac.nz> On 6/05/2011, at 7:04 PM, Lionel Cons wrote: > Richard O'Keefe writes: >>> In any case, the language must provide specific functions to work on strings >>> and characters. For instance, a logical character comparison must take into >>> account the Unicode equivalence. >> >> What do you mean "THE" equivalence? > > I mean what is described at http://en.wikipedia.org/wiki/Unicode_equivalence. Yes but that describes *TWO* notions of equivalence, not one. They are different, not just differently described. And with four normal forms, there are arguably four notions of equivalence. And when you start talking about collation, there are lots and lots more. > > Anyway, if logical characters are not supported, this is less relevant. Not really. Given two Unicode strings in any chosen representation, the distinction between "are these the same representations" and "are these the same string" exists, and the question of "what does it mean for two of these to be 'the same' string?" needs an answer, of which Unicode provides an abundance. From vasdeveloper@REDACTED Mon May 9 06:38:15 2011 From: vasdeveloper@REDACTED (Kannan) Date: Mon, 9 May 2011 10:08:15 +0530 Subject: [erlang-questions] gen_sctp documentation Message-ID: *Hi List,* * * *The following are the lines from gen_sctp documentation.* * * *recv(sctp_socket()) -> {ok, {FromIP, FromPort, AncData, BinMsg}} | {error, Reason} recv(sctp_socket(), timeout()) -> {ok, {FromIP, FromPort, AncData, Data}} | {error, Reason}* * * *Should not that "BinMsg" be "Data" instead, in a broader sense?* * * *Tanks.* -------------- next part -------------- An HTML attachment was scrubbed... URL: From masklinn@REDACTED Mon May 9 08:15:02 2011 From: masklinn@REDACTED (Masklinn) Date: Mon, 9 May 2011 08:15:02 +0200 Subject: [erlang-questions] byte() vs. char() use in documentation In-Reply-To: <0E4AB3DB-3830-40C8-BA3F-7AACF548C6F5@cs.otago.ac.nz> References: <20110502091415.GA6512@erix.ericsson.se> <20110503094549.GA10981@erix.ericsson.se> <201105040533.58985.als@iinet.net.au> <20110504075734.GA16456@erix.ericsson.se> <294BF31C-A04F-49C1-8CCB-E168D5AFAE5B@cs.otago.ac.nz> <60C82374-90CF-4200-9F87-1B662173A4B1@masklinn.net> <0E4AB3DB-3830-40C8-BA3F-7AACF548C6F5@cs.otago.ac.nz> Message-ID: <8B8AEC02-8555-4BC6-BE3D-E1A35E9057C1@masklinn.net> On 2011-05-09, at 05:45 , Richard O'Keefe wrote: > On 6/05/2011, at 6:49 PM, Masklinn wrote: >> On 2011-05-06, at 07:34 , Richard O'Keefe wrote: >>>> To come back to the point, we have to define what we mean with the Erlang >>>> char() type: >>>> - if it's an individual character then it can naturally be represented as >>>> a single integer for its code point >>>> - if it's a logical character then it has to be a list of integers >>> Since we cannot know what a logical character is, and since we need *some* >>> representation of Unicode code points, I recommend that char()=code point. >> Why pick code points rather than grapheme cluster? > > For so many many reasons I haven't the patience to list them all. > A. Because it is the simplest thing that could possibly work. Sure. But so would machine integers be in Erlang, yet the core team made a different choice. It is also, for most users, the most confusing choice by far. > B. Because grapheme clusters aren't any better a fit to the user's > perception of a "character" than code points. My experience runs counter to that. Do you have examples of codepoints sequences in which individual code points are better fit for a "user character" than the corresponding grapheme cluster? > C. Because Unicode properties are defined for characters, not > grapheme clusters. In most cases where this is of interest, either the cluster and the codepoint have a 1:1 mapping or you're only interested in the properties of the base character. Either way, this should not be much of an issue in 99.9% of cases (number pulled out of nowhere), and the base abstraction being grapheme clusters does not mean access to code points is prohibited to those who need such an access. > D. Because there is a finite and not *hopelessly* large set of > code points, but the set of grapheme clusters is unbounded The set of grapheme cluster is no more unbounded than the set of code points. Larger, maybe (probably), but code points are not arbitrarily combined into clusters. >>>> In any case, the language must provide specific functions to work on strings >>>> and characters. For instance, a logical character comparison must take into >>>> account the Unicode equivalence. >>> What do you mean "THE" equivalence?\ >> I would guess he means what he linked: unicode equivalence (as per unicode), >> likely compatible (in order to equate "?" with "ffi" for instance) > > Yes, but there are *several* notions of equivalence in the Unicode > standard, which was my point. Which of them is "THE" equivalence? > (The one with arguably the strongest claim does NOT deal with > compatibility mappings.) There are *two* equivalences, and one is a subset of the other. And I covered which equivalence would be most useful for a user non-versed in the details of Unicode (and ? one should assume ? not interested in them): compatibility equivalence, so that equivalence of ligatures is handled intuitively (as ligatures are typographical details which leaked into the standard, I think you would agree that, for most non-typographers, the aforementioned "?" and "ffi" are "the same thing", even though they are not canonically equivalent). From ingela.andin@REDACTED Mon May 9 09:59:21 2011 From: ingela.andin@REDACTED (Ingela Andin) Date: Mon, 9 May 2011 09:59:21 +0200 Subject: [erlang-questions] mochiweb https/ssl In-Reply-To: <1304710706.1860.3.camel@sasa-laptop> References: <1304632965.1894.13.camel@sasa-laptop> <1304710706.1860.3.camel@sasa-laptop> Message-ID: Hi! If you want to make sure that you run the new implementation you can use the option {ssl_imp, new} but if you run R14B02 and do not specify {ssl_imp, old} you should get the new one. When looking closer at your earlier post the occational error-report is from the new implementation, so I think that is not the issue. You mentioned that you could provide a test program, if you could send that to me so I can test it agaist the latest ssl code that would be great. All your problems might not have to do with erlang-ssl but it sure looks like there might be atleast one bug that needs fixing. Regards Ingela Erlang/OTP team - Ericsson AB 2011/5/6 sasa : > Hello, > > On Fri, 2011-05-06 at 21:30 +0200, Ingela Andin wrote: > > Where you using the old or the new erlang ssl implementation? Old ssl > scales poorly. > > If you use new ssl and not make any special configuration it will > always automatically > try to reuse sessions. (The server can refuse to reuse a session if it wants > to) > How the old implementation works I can not remember from the > top of my head but if you are using the old one I recomend upgrading > to the new one. > The new one is default in R14* and before that the old one is default. > I recomend R14. > > I am using erlang R14B02, so I suppose it is the new ssl. Is there any way I > can verify which implementation is actually used? Could it be that I was > missing some dependency during the compilation of the erlang and the old ssl > is actually used even though it is the version R14? > > Sasa > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > From sasa555@REDACTED Mon May 9 11:35:44 2011 From: sasa555@REDACTED (sasa) Date: Mon, 9 May 2011 11:35:44 +0200 Subject: [erlang-questions] mochiweb https/ssl In-Reply-To: References: <1304632965.1894.13.camel@sasa-laptop> <1304710706.1860.3.camel@sasa-laptop> Message-ID: Hello, First of all I would like to say that I tested the server on a 4 cores instance and it works very nicely with 2000 users. The load average is about 0.3 (it was about 9-10 with 2 cores), so it looks very good. I'll test with a larger number of clients, but so far it's a very big improvement. Unfortunately, as I switched to a larger instance, I immediately configured erlang with --enable-hipe so I'm not sure if that caused an improvement or is it due to the more CPU power. I'll play some more to find out. In any case, below is the code for the server. I don't know if I can post attachments to the mailing list so I embedded the code inline. The client code is very untidy at the moment, so I didn't include it. Basically it amounts to N processes which do following: ibrowse:send_req(Url, [{'Content-Type', 'application/x-www-form-urlencoded'}], post, "", [{ssl_options, [{depth, 0}]}, {max_sessions, 1000}, {max_pipeline_size, 1000}], 10000 ) The Url is a string such as "https://test-server.some.domain:9999 The server is in the file ssl_server.erl. I also didn't provide the SSL keys. -module(ssl_server). -export([start/0]). -define(HTTPS_OPTS, [ {port, 9999}, {name, https_test}, {ssl, true}, {ssl_opts, [ {ssl_imp, new}, {cacertfile, "keys/cacert.pem"}, {certfile, "keys/cert.pem"}, {keyfile, "keys/cert.key"}, {depth, 0} ]} ]). -define(HTTP_OPTS, [ {port, 8888}, {name, http_test} ]). start() -> application:start(crypto), application:start(ssl), {ok, FeederPid} = start_feed(), Loop = fun(Req) -> dispatch(Req, FeederPid) end, {ok, Https} = mochiweb_http:start([{loop, Loop} | ?HTTPS_OPTS]), {ok, Http} = mochiweb_http:start([{loop, Loop} | ?HTTP_OPTS]), wait_loop(). wait_loop() -> timer:sleep(60000), wait_loop(). % invoked from mochi web for each request dispatch(Req, FeederPid) -> FeederPid ! {add, self()}, % register with the feeder receive {respond, Message} -> % on feeder signal Req:ok({"text/plain", Message}) after 10000 -> Req:not_found() % timeout end. start_feed() -> FeederPid = proc_lib:spawn_link(fun feeder/0), % start feeder process proc_lib:spawn_link(fun() -> heartbeat(FeederPid) end), % start heartbeat process {ok, FeederPid}. % heartbeat - signal feeder in regular intervals heartbeat(Feeder) -> timer:sleep(5000), Feeder ! {broadcast, "message"}, heartbeat(Feeder). % feeder feeder() -> feeder([]). feeder(Children) -> NewChildren = receive {add, Child} -> % child registered [Child | Children]; {broadcast, Message} -> % heartbeat signaled io:format("broadcasting to ~p processes~n", [length(Children)]), lists:foreach(fun(Child) -> Child ! {respond, Message} end, Children), [] end, feeder(NewChildren). Best regards, Sasa On Mon, May 9, 2011 at 9:59 AM, Ingela Andin wrote: > Hi! > > If you want to make sure that you run the new implementation you can use the > option {ssl_imp, new} but if you run R14B02 and do not specify {ssl_imp, old} > you should get the new one. When looking closer at your earlier post > the occational error-report > is from the new implementation, so I think that is not the issue. You > mentioned that you could > provide a test program, if you could send that to me so I can test it > agaist the latest ssl code > that would be great. All your problems might not have to do with > erlang-ssl but it sure looks like > there might be atleast one bug that needs fixing. > > Regards Ingela Erlang/OTP team - Ericsson AB > > 2011/5/6 sasa : >> Hello, >> >> On Fri, 2011-05-06 at 21:30 +0200, Ingela Andin wrote: >> >> Where you using the old or the new erlang ssl implementation? Old ssl >> scales poorly. >> >> If you use new ssl and not make any special configuration it will >> always automatically >> try to reuse sessions. (The server can refuse to reuse a session if it wants >> to) >> How the old implementation works I can not remember from the >> top of my head but if you are using the old one I recomend upgrading >> to the new one. >> The new one is default in R14* and before that the old one is default. >> I recomend R14. >> >> I am using erlang R14B02, so I suppose it is the new ssl. Is there any way I >> can verify which implementation is actually used? Could it be that I was >> missing some dependency during the compilation of the erlang and the old ssl >> is actually used even though it is the version R14? >> >> Sasa >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Mon May 9 12:45:30 2011 From: max.lapshin@REDACTED (Max Lapshin) Date: Mon, 9 May 2011 14:45:30 +0400 Subject: [erlang-questions] Compiling erlang with static glibc for OTP releases Message-ID: I'm trying to migrate to OTP releases (using rebar) for erlyvideo. Goal is to minify problems, build dependencies and package build farm. I've compiled libcrypt in a static manner into erlang so, that there will be no problems on different versions (debian squeeze and debian sid use different versions), but problems go on: different versions of libc. I'm thinking about building erlang with all static dependencies so, that packages from one build machine will be useable on all 64bit linuxes. Is it a good idea to link erlang VM with glibc static? From steven.charles.davis@REDACTED Mon May 9 14:53:38 2011 From: steven.charles.davis@REDACTED (Steve Davis) Date: Mon, 9 May 2011 05:53:38 -0700 (PDT) Subject: [erlang-questions] byte() vs. char() use in documentation In-Reply-To: <4DB9951A.4050005@cs.ntua.gr> References: <4DB9951A.4050005@cs.ntua.gr> Message-ID: The problem with "string"s and "char"s is that they are not full specifications. It is not enough to say that strings are "just lists of integers" which has been a convenient shorthand. It could fully and equivalently be argued that *any data* is just a list of integers. The shorthand used historically in Erlang is that strings are list of integers that *implicitly represent a Latin-1 mapping to glyphs*. The issue, when other character sets are "allowed" becomes: which mapping does the value of char() represent? To say char() :: 0..16#10ffff is a type may allow for an Unicode mapping, but does not specify it. The value could be mapped to any glyph, since there is no longer the implicit constraint that the char() has a Latin 1 mapping, and so any user-defined choice of mapping becomes possible. This makes it impossible to tell which mapping is in use for that particular instance. People say that Erlang is "bad at string handling", but rather, I believe, Erlang (or rather the functional nature of Erlang) is showing that strings are simply a bad idea. Most languages choose/impose their own internal implicit mapping of this crazy "type" we call "string". e.g. Java says that all strings are Unicode mapped. If you decide to drop the constraint that chars and strings are no longer implicitly glyph-mapped by Latin 1, you must specify which encoding is in force in that context. I would argue therefore that string() and char() are therefore no longer useful or meaningful types, and that if you wish to define text representations in a type specification, you had better provide not just the data but a specification of the glyph map that is in force, and so the decoding of that data can be determined by a function, a situation which the string() and char() notation imply must be possible. /s On Apr 28, 11:26?am, Kostis Sagonas wrote: > In the Erlang documentation, the language of types and specs makes a > clear distinction between the following two types: > > ? ? ?byte() :: 0..255 > ? ? ?char() :: 0..16#10ffff From frank.usenet.mail@REDACTED Mon May 9 17:30:44 2011 From: frank.usenet.mail@REDACTED (Frank) Date: Mon, 9 May 2011 11:30:44 -0400 Subject: [erlang-questions] Integrating Erlang and OpenSAF Message-ID: Hi, I've been trying to get up to speed with the SAF (Service Availability Framework - HA middleware) implementation OpenSAF (http://www.opensaf.org/) and I was wondering if there were ways to integrate Erlang with it? They already seem to provide APIs for Java and C. Since Ericsson seems to be backing both OpenSAF and Erlang ( http://www.ericsson.com/article/open_source_1714451213_c), an Erlang implementation might make sense as well :) P.S. I've been trying to send this email through another email account and it didn't seem to make it to the list. If it does make it in the end then I'm sorry for the multiple posts... Thanks, Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan@REDACTED Mon May 9 18:01:32 2011 From: ivan@REDACTED (Ivan Uemlianin) Date: Mon, 09 May 2011 17:01:32 +0100 Subject: [erlang-questions] Appmon, pman on MacOSX Message-ID: <4DC80FDC.5010102@llaisdy.com> Dear All I'm running erlang R13B01 on MacOSX.6. I've just tried to launch appmon from the erlang shell and got this error (and no appmon): dyld: Library not loaded: /opt/local/lib/libX11.6.dylib Referenced from: /opt/local/bin/wish8.5 Reason: no suitable image found. Did find: /opt/local/lib/libX11.6.dylib: mach-o, but wrong architecture I've done a quick google but found nothing, so I'm about to go deeper. In the meantime, has anybody else come up against this and found out how to fix it? With thanks and best wishes Ivan -- ============================================================ Ivan A. Uemlianin Speech Technology Research and Development ivan@REDACTED www.llaisdy.com llaisdy.wordpress.com www.linkedin.com/in/ivanuemlianin "Froh, froh! Wie seine Sonnen, seine Sonnen fliegen" (Schiller, Beethoven) ============================================================ From nox@REDACTED Mon May 9 19:02:52 2011 From: nox@REDACTED (Anthony Ramine) Date: Mon, 9 May 2011 19:02:52 +0200 Subject: [erlang-questions] Appmon, pman on MacOSX In-Reply-To: <4DC80FDC.5010102@llaisdy.com> References: <4DC80FDC.5010102@llaisdy.com> Message-ID: <4E061181-B86D-4DE3-B285-D224AAEB603E@dev-extend.eu> This is a MacPorts problem, you should probably rebuild xorg-libX11 and all of its dependencies and dependents. Le 9 mai 2011 ? 18:01, Ivan Uemlianin a ?crit : > Dear All > > I'm running erlang R13B01 on MacOSX.6. I've just tried to launch appmon from the erlang shell and got this error (and no appmon): > > dyld: Library not loaded: /opt/local/lib/libX11.6.dylib > Referenced from: /opt/local/bin/wish8.5 > Reason: no suitable image found. Did find: > /opt/local/lib/libX11.6.dylib: mach-o, but wrong architecture > > I've done a quick google but found nothing, so I'm about to go deeper. > > In the meantime, has anybody else come up against this and found out how to fix it? > > With thanks and best wishes > > Ivan > > > -- > ============================================================ > Ivan A. Uemlianin > Speech Technology Research and Development > > ivan@REDACTED > www.llaisdy.com > llaisdy.wordpress.com > www.linkedin.com/in/ivanuemlianin > > "Froh, froh! Wie seine Sonnen, seine Sonnen fliegen" > (Schiller, Beethoven) > ============================================================ > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Anthony Ramine Dev:Extend http://dev-extend.eu From ivan@REDACTED Mon May 9 19:26:18 2011 From: ivan@REDACTED (Ivan Uemlianin) Date: Mon, 9 May 2011 18:26:18 +0100 Subject: [erlang-questions] Appmon, pman on MacOSX In-Reply-To: <4E061181-B86D-4DE3-B285-D224AAEB603E@dev-extend.eu> References: <4DC80FDC.5010102@llaisdy.com> <4E061181-B86D-4DE3-B285-D224AAEB603E@dev-extend.eu> Message-ID: <2E4BFCCB-5318-4189-BDEB-EE1B82AE5F1C@llaisdy.com> Thanks, I didn't know I could do that. I think I might have to do something with MacPorts itself too, as I probably installed it under MacOS 10.5. I rue the day I ever touched MacPorts. Package management on the mac is so bad I'm definitely going back to Debian on my next machine. Best wishes Ivan Sent from iPhone. On 9 May 2011, at 18:02, Anthony Ramine wrote: > This is a MacPorts problem, you should probably rebuild xorg-libX11 and all of its dependencies and dependents. > > Le 9 mai 2011 ? 18:01, Ivan Uemlianin a ?crit : > >> Dear All >> >> I'm running erlang R13B01 on MacOSX.6. I've just tried to launch appmon from the erlang shell and got this error (and no appmon): >> >> dyld: Library not loaded: /opt/local/lib/libX11.6.dylib >> Referenced from: /opt/local/bin/wish8.5 >> Reason: no suitable image found. Did find: >> /opt/local/lib/libX11.6.dylib: mach-o, but wrong architecture >> >> I've done a quick google but found nothing, so I'm about to go deeper. >> >> In the meantime, has anybody else come up against this and found out how to fix it? >> >> With thanks and best wishes >> >> Ivan >> >> >> -- >> ============================================================ >> Ivan A. Uemlianin >> Speech Technology Research and Development >> >> ivan@REDACTED >> www.llaisdy.com >> llaisdy.wordpress.com >> www.linkedin.com/in/ivanuemlianin >> >> "Froh, froh! Wie seine Sonnen, seine Sonnen fliegen" >> (Schiller, Beethoven) >> ============================================================ >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > -- > Anthony Ramine > Dev:Extend > http://dev-extend.eu > > > > From paul.joseph.davis@REDACTED Mon May 9 19:30:03 2011 From: paul.joseph.davis@REDACTED (Paul Davis) Date: Mon, 9 May 2011 13:30:03 -0400 Subject: [erlang-questions] Appmon, pman on MacOSX In-Reply-To: <2E4BFCCB-5318-4189-BDEB-EE1B82AE5F1C@llaisdy.com> References: <4DC80FDC.5010102@llaisdy.com> <4E061181-B86D-4DE3-B285-D224AAEB603E@dev-extend.eu> <2E4BFCCB-5318-4189-BDEB-EE1B82AE5F1C@llaisdy.com> Message-ID: 2011/5/9 Ivan Uemlianin : > Thanks, I didn't know I could do that. I think I might have to do something with MacPorts itself too, as I probably installed it under MacOS 10.5. > > I rue the day I ever touched MacPorts. Package management on the mac is so bad I'm definitely going back to Debian on my next machine. > > Best wishes > > Ivan > > Sent from iPhone. > > On 9 May 2011, at 18:02, Anthony Ramine wrote: > >> This is a MacPorts problem, you should probably rebuild xorg-libX11 and all of its dependencies and dependents. >> >> Le 9 mai 2011 ? 18:01, Ivan Uemlianin a ?crit : >> >>> Dear All >>> >>> I'm running erlang R13B01 on MacOSX.6. ?I've just tried to launch appmon from the erlang shell and got this error (and no appmon): >>> >>> ? dyld: Library not loaded: /opt/local/lib/libX11.6.dylib >>> ? Referenced from: /opt/local/bin/wish8.5 >>> ? Reason: no suitable image found. ?Did find: >>> ? /opt/local/lib/libX11.6.dylib: mach-o, but wrong architecture >>> >>> I've done a quick google but found nothing, so I'm about to go deeper. >>> >>> In the meantime, has anybody else come up against this and found out how to fix it? >>> >>> With thanks and best wishes >>> >>> Ivan >>> >>> >>> -- >>> ============================================================ >>> Ivan A. Uemlianin >>> Speech Technology Research and Development >>> >>> ? ? ? ? ? ? ? ? ? ivan@REDACTED >>> ? ? ? ? ? ? ? ? ? ?www.llaisdy.com >>> ? ? ? ? ? ? ? ? ? ? ? ?llaisdy.wordpress.com >>> ? ? ? ? ? ? ? ? ? ?www.linkedin.com/in/ivanuemlianin >>> >>> ? "Froh, froh! Wie seine Sonnen, seine Sonnen fliegen" >>> ? ? ? ? ? ? ? ? ? ?(Schiller, Beethoven) >>> ============================================================ >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> >> -- >> Anthony Ramine >> Dev:Extend >> http://dev-extend.eu >> >> >> >> > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > You might also want to check out Homebrew [1] for OS X "package management". [1] https://github.com/mxcl/homebrew From michael.s.klishin@REDACTED Mon May 9 19:43:22 2011 From: michael.s.klishin@REDACTED (Michael Klishin) Date: Mon, 9 May 2011 21:43:22 +0400 Subject: [erlang-questions] Appmon, pman on MacOSX In-Reply-To: References: <4DC80FDC.5010102@llaisdy.com> <4E061181-B86D-4DE3-B285-D224AAEB603E@dev-extend.eu> <2E4BFCCB-5318-4189-BDEB-EE1B82AE5F1C@llaisdy.com> Message-ID: <6777413F7122407DB1407B7572B6E951@gmail.com> Ivan, Many developers running Mac OS X these days use Homebrew: http://mxcl.github.com/homebrew, give it a try. -- MK 2011/5/9 Ivan Uemlianin : > > > > I rue the day I ever touched MacPorts. Package management on the mac is so bad I'm definitely going back to Debian on my next machine. From ivan@REDACTED Mon May 9 19:46:32 2011 From: ivan@REDACTED (Ivan Uemlianin) Date: Mon, 9 May 2011 18:46:32 +0100 Subject: [erlang-questions] Appmon over ssh Message-ID: Dear all I have an erlang app on a remote server that I'd like to monitor with appmon and pman. How can I do that? Can I do either of these: 1. use some ssh incantation to run appmon on the remote machine but have the GUI appear locally (and would this work if my local tcl is broken, which it is currently). 2. add my machine as a node to the remote machine and then run appmon locally to view the remote app. With thanks and best wishes Ivan Sent from iPhone. From spawn.think@REDACTED Mon May 9 21:26:22 2011 From: spawn.think@REDACTED (Ahmed Omar) Date: Mon, 9 May 2011 21:26:22 +0200 Subject: [erlang-questions] Appmon over ssh In-Reply-To: References: Message-ID: The 2nd option will work fine. When you run appmon or pman you will find a menu called Nodes, you can switch to view any of your connected nodes. On Mon, May 9, 2011 at 7:46 PM, Ivan Uemlianin wrote: > Dear all > > I have an erlang app on a remote server that I'd like to monitor with > appmon and pman. How can I do that? Can I do either of these: > > 1. use some ssh incantation to run appmon on the remote machine but have > the GUI appear locally (and would this work if my local tcl is broken, which > it is currently). > > 2. add my machine as a node to the remote machine and then run appmon > locally to view the remote app. > > With thanks and best wishes > > Ivan > > Sent from iPhone. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think -------------- next part -------------- An HTML attachment was scrubbed... URL: From thatpythonguy@REDACTED Mon May 9 21:33:07 2011 From: thatpythonguy@REDACTED (Ahmed Al-Saadi) Date: Mon, 09 May 2011 15:33:07 -0400 Subject: [erlang-questions] Appmon, pman on MacOSX In-Reply-To: <6777413F7122407DB1407B7572B6E951@gmail.com> References: <4DC80FDC.5010102@llaisdy.com> <4E061181-B86D-4DE3-B285-D224AAEB603E@dev-extend.eu> <2E4BFCCB-5318-4189-BDEB-EE1B82AE5F1C@llaisdy.com> <6777413F7122407DB1407B7572B6E951@gmail.com> Message-ID: <4DC84173.30902@gmail.com> Ivan: I use Homebrew which is great, but I had to compile my Erlang from source as I had some issues with wx apps that, though different than yours, were resolved by a source install. It appears that the Homebrew erlang package was missing some libraries. Btw, Homebrew installs in a self-contained tree and can be mixed with your macports packages as long as you make sure its path is seen first. Let us know how you resolve this! Cheers, -signed(ahmed). On 5/9/11 1:43 PM, Michael Klishin wrote: > Ivan, > > Many developers running Mac OS X these days use Homebrew: http://mxcl.github.com/homebrew, give it a try. > From attila.r.nohl@REDACTED Mon May 9 21:42:54 2011 From: attila.r.nohl@REDACTED (Attila Rajmund Nohl) Date: Mon, 9 May 2011 21:42:54 +0200 Subject: [erlang-questions] Appmon over ssh In-Reply-To: References: Message-ID: 2011/5/9, Ivan Uemlianin : > Dear all > > I have an erlang app on a remote server that I'd like to monitor with appmon > and pman. How can I do that? Can I do either of these: > > 1. use some ssh incantation to run appmon on the remote machine but have the > GUI appear locally (and would this work if my local tcl is broken, which it > is currently). If you're using a UNIX-like operating system both locally and remote, you can use X11 forwarding in ssh, something like this: ssh -X This will work even if your local tcl is broken. However, on a high latency link this will require much patience... From ok@REDACTED Tue May 10 04:14:31 2011 From: ok@REDACTED (Richard O'Keefe) Date: Tue, 10 May 2011 14:14:31 +1200 Subject: [erlang-questions] byte() vs. char() use in documentation In-Reply-To: <8B8AEC02-8555-4BC6-BE3D-E1A35E9057C1@masklinn.net> References: <20110502091415.GA6512@erix.ericsson.se> <20110503094549.GA10981@erix.ericsson.se> <201105040533.58985.als@iinet.net.au> <20110504075734.GA16456@erix.ericsson.se> <294BF31C-A04F-49C1-8CCB-E168D5AFAE5B@cs.otago.ac.nz> <60C82374-90CF-4200-9F87-1B662173A4B1@masklinn.net> <0E4AB3DB-3830-40C8-BA3F-7AACF548C6F5@cs.otago.ac.nz> <8B8AEC02-8555-4BC6-BE3D-E1A35E9057C1@masklinn.net> Message-ID: <974410F2-973C-419E-B387-35D764A636B4@cs.otago.ac.nz> Let's start by quoting the Unicode standard itself. Chapter 5: Data types for ?characters? generally hold just a single Unicode code point value for low-level processing and lookup of character property values. When a primitive data type is used for single-code point values, a signed integer type can be useful; negative values can hold ?sentinel? values like end-of-string or end-of-file, which can be easily distinguished from Unicode code point values. However, in most APIs, string types should be used to accommodate user-perceived characters, which may require sequences of code points. If I'm reading this correctly, the recommendation is to have TWO ways of representing textual information in the same language and even in the same program: BOTH a one 'character' = one code point = one integer version AND a one 'string' = one 'user-perceived character'. It's truly unfortunate that determining what some particular user perceives as a character is so hard. On 9/05/2011, at 6:15 PM, Masklinn wrote: >>> Why pick code points rather than grapheme cluster? >> >> For so many many reasons I haven't the patience to list them all. >> A. Because it is the simplest thing that could possibly work. > Sure. But so would machine integers be in Erlang, yet the core team > made a different choice. > > It is also, for most users, the most confusing choice by far. The word "user" is hopelessly confusing in itself. For end-users, the representation used in the programming language should be a matter of complete indifference. For *programmers*, I don't see "one thing defined in Unicode = one thing manipulated in the program" as particularly confusing; anything else (such as grapheme clusters) would confuse *me* a great deal more. Such confusion as exists is because Unicode is confusing. At least if people deal with the things that are defined by Unicode they can appeal to the Unicode standard itself for help. Note that Extended Combining Character Sequence (in ch3, s D56) Combining Character Sequence (in ch3, s D56) Grapheme Cluster (in ch3, ss D57-D60) Extended Grapheme Cluster (in ch3, s D61) are not identical. Amongst other things, the grapheme base (D58) of a grapheme cluster (D60) may be a block of syllables, which would have counted as separate CCSs. We are warned that grapheme clusters "do not have linguistic significance" and I for one am really worried about the licence given in D61 for "tailoring", so that the question of which code point sequences count as a grapheme cluster is NOT application-independent. Then there is the fact that a text in Unicode will usually contain many code points that do not form part of any grapheme cluster, which means that "String = sequence of grapheme clusters" is NOT one of the schemes 'that could possibly work'. > >> B. Because grapheme clusters aren't any better a fit to the user's >> perception of a "character" than code points. > My experience runs counter to that. Do you have examples of codepoints > sequences in which individual code points are better fit for a > "user character" than the corresponding grapheme cluster? I have already provided such an example: ?. In *SOME* cases that counts as a single "character" for the end-user; in *SOME* cases it counts as two "characters". When I write "the noun is 'pr?test', the verb 'prot?st'" I perceive this as writing two conceptually distinct and physically separate characters in the same column, a vowel and a stress accent. In handwriting, I might even write the word and then go back and write the accent. If I were searching for "protest" I would be happy for the program to find either of the marked occurrences. But let me turn this around. There are code points in Unicode that don't correspond to user-perceptible characters AT ALL, and therefore cannot meaningfully be considered as part of "grapheme clusters". Take the language tag code points in plane 14, for example. Take them far away and burn them, as a matter of fact. But there are plenty of other invisible code points with semantic effects in Chapter 16 of Unicode 6.0. Note, for example, that if a control or format character is followed by one or more combining characters, the combining characters form a "defective combining character sequence" (chapter 3, D57), which does NOT include that format or control character. > >> C. Because Unicode properties are defined for characters, not >> grapheme clusters. > In most cases where this is of interest, either the cluster and > the codepoint have a 1:1 mapping or you're only interested in > the properties of the base character. How did you measure this? > Either way, this should > not be much of an issue in 99.9% of cases (number pulled out of > nowhere), Ah. "Number pulled out of nowhere." Then I don't have to take it any more seriously than you did. > and the base abstraction being grapheme clusters does > not mean access to code points is prohibited to those who need > such an access. Conversely: the base abstraction being code points does not mean that access to grapheme clusters is prohibited to those who need such an access. > >> D. Because there is a finite and not *hopelessly* large set of >> code points, but the set of grapheme clusters is unbounded > The set of grapheme cluster is no more unbounded than the set of > code points. Larger, maybe (probably), but code points are not > arbitrarily combined into clusters. Where did you get that idea? The Unicode standard does not place any limit on the number of combining characters that may be attached to a base character (or may in the case of a defective CCS be floating around without any base character). In fact the book explicitly denies the existence of such a bound: This rendering behavior for nonspacing marks can be generalized to SEQUENCES OF ANY LENGTH, although practical considerations usually limit such sequences to no more than two or three marks above and/or below a grapheme base. The practical considerations here refer to rendering; for text that is not going to be rendered there are no such practical considerations. In any case, Unicode 4.0 had about 800 non-spacing marks, and 3 above + 3 below gives 2.6e17 variants for *each* base character. I agree that long combining sequences may be *rare* (mostly occurring as jokes or test cases) but they are *allowed*. >> Yes, but there are *several* notions of equivalence in the Unicode >> standard, which was my point. Which of them is "THE" equivalence? >> (The one with arguably the strongest claim does NOT deal with >> compatibility mappings.) > There are *two* equivalences, and one is a subset of the other. With more than two normal forms, there are more than two notions of equivalence. Then too, each revision of Unicode subtly changes both the canonical and the compatibility equivalences. > > And I covered which equivalence would be most useful for a user non-versed > in the details of Unicode (and ? one should assume ? not interested in them): > compatibility equivalence, However, that is NOT the notion of equivalence that is preferred by the standard itself, which is canonical equivalence. "All processes .. are required to abide by [the] conformance clause" which defines replacing a character by a compatibility equivalent as a modification to the interpretation of the text. This means that a typical Erlang program, shipping data around the network, MUST NOT do compatibility mapping by default. That should ONLY be done where a higher level protocol explicitly allows it. As "Unicode in XML and other Markup Languages" (revision 8) says, "It is never advisable to apply compatibility mappings indiscriminately." A user non-versed in the details of Unicode should not be programming Unicode applications in Erlang. We agree 100% that components and algorithms should be available to let Erlang programmers manipulate text in ways appropriate for the application at hand. Where we disagree is just how much superhuman intelligence needs to be built into the core. > so that equivalence of ligatures is handled > intuitively (as ligatures are typographical details which leaked into the > standard, I think you would agree that, for most non-typographers, the > aforementioned "?" and "ffi" are "the same thing", even though they are > not canonically equivalent). Indeed. But that's really not going to work well enough. I personally perceive the letter ash (??) as a distinct letter, not as a ligature. Unicode calls it "LATIN (CAPITAL|SMALL) LETTER AE", not a ligature, unlike "LATIN (CAPITAL|SMALL) LIGATURE OE". In the English-speaking world, I suspect that most people would perceive ash as an ae ligature. If you want to handle ligatures intuitively, you should regard ? and AE as equivalent, even though they are NOT compatibility equivalent. This means that using the somewhat risky compatibility equivalence is *NOT* sufficient to handle ligatures intuitively. Even with characters whose names include "LIGATURE", some (like IJ) do have compatibility mappings, and some (like OE) do not. In short, dealing with Unicode is flaming hard, and using compatibilty-equivalent grapheme clusters is NOT going to make many (if indeed any) of our problems go away. > From wsong.cn@REDACTED Tue May 10 05:50:28 2011 From: wsong.cn@REDACTED (Wenqiang Song) Date: Tue, 10 May 2011 11:50:28 +0800 Subject: [erlang-questions] Erlang proccess memory usage Message-ID: Hi, I'm experimenting with Erlang process and found something that not expected. What I do is creating 1M Erlang processes and measure memory usage. Code is as follow: -module(generator). -export([start/0, generator/2, loop/0]). start() -> Pid = self(), spawn( fun()->generator(19,Pid) end ), count (1). count (Num) -> receive add -> % io:format("Oopss, ~n"), if 0 =:= ( Num rem 10000 ) -> io:format("Count ~p~n", [Num]); true -> Q = 3 end, count (Num + 1); _ -> io:format("haha, ~n") after 30000 -> io:format("Count ~p~n", [Num]), count (Num) end. loop() -> receive _ -> io:format("Oops ~n"), % proc_lib:hibernate(?MODULE, loop(), []) loop() end. generator( 0, Pid ) -> Pid ! add, % proc_lib:hibernate(?MODULE, loop(), []); loop(); generator( Depth, Pid ) -> spawn( fun()->generator(Depth - 1, Pid) end), spawn( fun()->generator(Depth - 1, Pid) end), Pid ! add, % io:format("Depth: ~p, pid: ~p~n", [Depth, Pid]), % proc_lib:hibernate(?MODULE, loop(), []). loop(). ===============End of Code============= 2> i(0,58,0). [{current_function,{generator,loop,0}}, {initial_call,{erlang,apply,2}}, {status,waiting}, {message_queue_len,0}, {messages,[]}, {links,[]}, {dictionary,[]}, {trap_exit,false}, {error_handler,error_handler}, {priority,normal}, {group_leader,<0.25.0>}, {total_heap_size,233}, {heap_size,233}, {stack_size,1}, {reductions,9}, {garbage_collection,[{min_bin_vheap_size,46368}, {min_heap_size,233}, {fullsweep_after,65535}, {minor_gcs,0}]}, {suspending,[]}] 3> memory(). [{total,2759895784}, {processes,2751081712}, {processes_used,2751067504}, {system,8814072}, {atom,615121}, {atom_used,589205}, {binary,8608}, {code,5845747}, {ets,270928}] Total memory usage is about 2.7G. While when I use i() and i(pid) I saw that each process only uses about 233 bytes. I can't find where the memory is used. Any idea? Thanks Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From wsong.cn@REDACTED Tue May 10 05:55:04 2011 From: wsong.cn@REDACTED (Wenqiang Song) Date: Tue, 10 May 2011 11:55:04 +0800 Subject: [erlang-questions] Erlang proccess memory usage In-Reply-To: References: Message-ID: Also I tried to use proc_lib:hibernate/3 with no difference. On Tue, May 10, 2011 at 11:50 AM, Wenqiang Song wrote: > Hi, > > I'm experimenting with Erlang process and found something that not > expected. > > What I do is creating 1M Erlang processes and measure memory usage. Code is > as follow: > -module(generator). > -export([start/0, generator/2, loop/0]). > > start() -> > Pid = self(), > spawn( fun()->generator(19,Pid) end ), > count (1). > > count (Num) -> > receive > add -> > % io:format("Oopss, ~n"), > if > 0 =:= ( Num rem 10000 ) -> io:format("Count ~p~n", [Num]); > true -> Q = 3 > end, > count (Num + 1); > _ -> > io:format("haha, ~n") > after 30000 -> > io:format("Count ~p~n", [Num]), > count (Num) > end. > loop() -> > receive > _ -> > io:format("Oops ~n"), > % proc_lib:hibernate(?MODULE, loop(), []) > loop() > end. > generator( 0, Pid ) -> > Pid ! add, > % proc_lib:hibernate(?MODULE, loop(), []); > loop(); > generator( Depth, Pid ) -> > spawn( fun()->generator(Depth - 1, Pid) end), > spawn( fun()->generator(Depth - 1, Pid) end), > Pid ! add, > % io:format("Depth: ~p, pid: ~p~n", [Depth, Pid]), > % proc_lib:hibernate(?MODULE, loop(), []). > loop(). > ===============End of Code============= > 2> i(0,58,0). > [{current_function,{generator,loop,0}}, > {initial_call,{erlang,apply,2}}, > {status,waiting}, > {message_queue_len,0}, > {messages,[]}, > {links,[]}, > {dictionary,[]}, > {trap_exit,false}, > {error_handler,error_handler}, > {priority,normal}, > {group_leader,<0.25.0>}, > {total_heap_size,233}, > {heap_size,233}, > {stack_size,1}, > {reductions,9}, > {garbage_collection,[{min_bin_vheap_size,46368}, > {min_heap_size,233}, > {fullsweep_after,65535}, > {minor_gcs,0}]}, > {suspending,[]}] > > 3> memory(). > [{total,2759895784}, > {processes,2751081712}, > {processes_used,2751067504}, > {system,8814072}, > {atom,615121}, > {atom_used,589205}, > {binary,8608}, > {code,5845747}, > {ets,270928}] > > Total memory usage is about 2.7G. While when I use i() and i(pid) I saw > that each process only uses about 233 bytes. I can't find where the memory > is used. Any idea? > > Thanks > Andy > -- ???????????????????? ???????????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: From silent_vendetta@REDACTED Tue May 10 06:29:12 2011 From: silent_vendetta@REDACTED (Chris Hicks) Date: Mon, 9 May 2011 21:29:12 -0700 Subject: [erlang-questions] Erlang proccess memory usage In-Reply-To: References: , Message-ID: The first problem you are running into is that you are mistaking "words" for "bytes" see: http://www.erlang.org/doc/efficiency_guide/advanced.html With that information in mind this is what you are really looking at for 1M processes: From: wsong.cn@REDACTED Date: Tue, 10 May 2011 11:55:04 +0800 To: erlang-questions@REDACTED Subject: Re: [erlang-questions] Erlang proccess memory usage Also I tried to use proc_lib:hibernate/3 with no difference. On Tue, May 10, 2011 at 11:50 AM, Wenqiang Song wrote: Hi, I'm experimenting with Erlang process and found something that not expected. What I do is creating 1M Erlang processes and measure memory usage. Code is as follow: -module(generator).-export([start/0, generator/2, loop/0]). start() -> Pid = self(), spawn( fun()->generator(19,Pid) end ), count (1). count (Num) -> receive add ->% io:format("Oopss, ~n"), if 0 =:= ( Num rem 10000 ) -> io:format("Count ~p~n", [Num]); true -> Q = 3 end, count (Num + 1); _ -> io:format("haha, ~n") after 30000 -> io:format("Count ~p~n", [Num]), count (Num) end. loop() -> receive _ -> io:format("Oops ~n"), % proc_lib:hibernate(?MODULE, loop(), []) loop() end. generator( 0, Pid ) -> Pid ! add,% proc_lib:hibernate(?MODULE, loop(), []); loop();generator( Depth, Pid ) -> spawn( fun()->generator(Depth - 1, Pid) end), spawn( fun()->generator(Depth - 1, Pid) end), Pid ! add,% io:format("Depth: ~p, pid: ~p~n", [Depth, Pid]),% proc_lib:hibernate(?MODULE, loop(), []). loop().===============End of Code=============2> i(0,58,0).[{current_function,{generator,loop,0}}, {initial_call,{erlang,apply,2}}, {status,waiting}, {message_queue_len,0}, {messages,[]}, {links,[]}, {dictionary,[]}, {trap_exit,false}, {error_handler,error_handler}, {priority,normal}, {group_leader,<0.25.0>}, {total_heap_size,233}, {heap_size,233}, {stack_size,1}, {reductions,9}, {garbage_collection,[{min_bin_vheap_size,46368}, {min_heap_size,233}, {fullsweep_after,65535}, {minor_gcs,0}]}, {suspending,[]}] 3> memory().[{total,2759895784}, {processes,2751081712}, {processes_used,2751067504}, {system,8814072}, {atom,615121}, {atom_used,589205}, {binary,8608}, {code,5845747}, {ets,270928}] Total memory usage is about 2.7G. While when I use i() and i(pid) I saw that each process only uses about 233 bytes. I can't find where the memory is used. Any idea? ThanksAndy -- ???????????????????? ???????????????????? _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From silent_vendetta@REDACTED Tue May 10 06:38:13 2011 From: silent_vendetta@REDACTED (Chris Hicks) Date: Mon, 9 May 2011 21:38:13 -0700 Subject: [erlang-questions] Erlang proccess memory usage In-Reply-To: References: , , , Message-ID: Bless hotmail for sending an e-mail on an attempted paste of text...as I was saying With that information in mind this is what you are really looking at for 1M processes: 233 words1 word = 4 bytes on 32 bit system1 word = 8 bytes on 64 bit system 233 * 4 = 932 bytes on 32 bit system233 * 8 = 1864 bytes on 64 bit system 1M procs * 932 bytes = 932,000,000 / 1000 / 1000 / 1000 = .932 GB on 32 bit system1M procs * 1864 bytes = 1,864,000,000 / 1000 / 1000 / 1000 = 1.864 GB on 64 bit system The thing that is a bit confusing is that memory() displays the amount used in bytes, whereas any process info appears to return the amount of memory used in words. That still doesn't get you to your 2.7 gigs used, but it should help explain a decent chunk of where that memory went. Chris Hicks.From: silent_vendetta@REDACTED To: erlang-questions@REDACTED Date: Mon, 9 May 2011 21:29:12 -0700 Subject: Re: [erlang-questions] Erlang proccess memory usage The first problem you are running into is that you are mistaking "words" for "bytes" see: http://www.erlang.org/doc/efficiency_guide/advanced.html With that information in mind this is what you are really looking at for 1M processes: From: wsong.cn@REDACTED Date: Tue, 10 May 2011 11:55:04 +0800 To: erlang-questions@REDACTED Subject: Re: [erlang-questions] Erlang proccess memory usage Also I tried to use proc_lib:hibernate/3 with no difference. On Tue, May 10, 2011 at 11:50 AM, Wenqiang Song wrote: Hi, I'm experimenting with Erlang process and found something that not expected. What I do is creating 1M Erlang processes and measure memory usage. Code is as follow: -module(generator).-export([start/0, generator/2, loop/0]). start() -> Pid = self(), spawn( fun()->generator(19,Pid) end ), count (1). count (Num) -> receive add ->% io:format("Oopss, ~n"), if 0 =:= ( Num rem 10000 ) -> io:format("Count ~p~n", [Num]); true -> Q = 3 end, count (Num + 1); _ -> io:format("haha, ~n") after 30000 -> io:format("Count ~p~n", [Num]), count (Num) end. loop() -> receive _ -> io:format("Oops ~n"), % proc_lib:hibernate(?MODULE, loop(), []) loop() end. generator( 0, Pid ) -> Pid ! add,% proc_lib:hibernate(?MODULE, loop(), []); loop();generator( Depth, Pid ) -> spawn( fun()->generator(Depth - 1, Pid) end), spawn( fun()->generator(Depth - 1, Pid) end), Pid ! add,% io:format("Depth: ~p, pid: ~p~n", [Depth, Pid]),% proc_lib:hibernate(?MODULE, loop(), []). loop().===============End of Code=============2> i(0,58,0).[{current_function,{generator,loop,0}}, {initial_call,{erlang,apply,2}}, {status,waiting}, {message_queue_len,0}, {messages,[]}, {links,[]}, {dictionary,[]}, {trap_exit,false}, {error_handler,error_handler}, {priority,normal}, {group_leader,<0.25.0>}, {total_heap_size,233}, {heap_size,233}, {stack_size,1}, {reductions,9}, {garbage_collection,[{min_bin_vheap_size,46368}, {min_heap_size,233}, {fullsweep_after,65535}, {minor_gcs,0}]}, {suspending,[]}] 3> memory().[{total,2759895784}, {processes,2751081712}, {processes_used,2751067504}, {system,8814072}, {atom,615121}, {atom_used,589205}, {binary,8608}, {code,5845747}, {ets,270928}] Total memory usage is about 2.7G. While when I use i() and i(pid) I saw that each process only uses about 233 bytes. I can't find where the memory is used. Any idea? ThanksAndy -- ???????????????????? ???????????????????? _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From t.greenwoodgeer@REDACTED Tue May 10 08:58:38 2011 From: t.greenwoodgeer@REDACTED (Todd) Date: Mon, 09 May 2011 23:58:38 -0700 Subject: [erlang-questions] api to retrieve module documentation (comparison to python shell) Message-ID: <4DC8E21E.50802@gmail.com> Is it possible to retrieve the documentation or the source for a given method? 1. I'd can to enumerate the loaded modules: (nitrogen@REDACTED)18> erlang:loaded(). [sys_expand_pmod,eunit_autoexport,security_handler, route_handler,role_handler,identity_handler,cache_handler, eval_bits,cerl_trees,lib,action_hide,action_jquery_effect, action_show,element_link,net_adm,process_registry_handler, session_handler,element_placeholder,element_listitem, element_bind,element_list,action_update,wf_validation, element_span,processes,epp,log_handler,file_not_found_page, re|...] 2. And I can get the exported methods for a given module: (nitrogen@REDACTED)25> [{exports, Exports}, _, _, _] = net_adm:module_info(). [{exports,[{host_file,0}, {localhost,0}, {names,0}, {names,1}, {dns_hostname,1}, {ping_list,1}, {world,0}, {world,1}, {world_list,1}, {world_list,2}, {module_info,0}, {module_info,1}, {ping,1}]}, {imports,[]}, {attributes,[{vsn,[82065340652727412467812120004278067483]}]}, {compile,[{options,[{cwd,"/home/user/erlang/otp_src_R14B02/lib/kernel/src"}, {outdir,"/home/user/erlang/otp_src_R14B02/lib/kernel/src/../ebin"}, {i,"/home/user/erlang/otp_src_R14B02/lib/kernel/src/../include"}, debug_info]}, {version,"4.7.3"}, {time,{2011,4,26,3,21,35}}, {source,"/home/user/erlang/otp_src_R14B02/lib/kernel/src/net_adm.erl"}]}] (nitrogen@REDACTED)26> Exports. [{host_file,0}, {localhost,0}, {names,0}, {names,1}, {dns_hostname,1}, {ping_list,1}, {world,0}, {world,1}, {world_list,1}, {world_list,2}, {module_info,0}, {module_info,1}, {ping,1}] 3. But now I'd like to get the docstring and/or the source for a given module:export. Is there an existing api method that does this? BTW - this is the sort of thing that python is really good at. I love being able to simply type "dir()" and navigate through the local environment and into objects. For example, running the python shell: a) look at the local environment >>> dir() ['__builtins__', '__doc__', '__name__', '__package__'] b) examine an entry >>> dir (__doc__) ['__class__', '__delattr__', '__doc__', '__format__', '__getattribute__', '__hash__', '__init__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__'] c) create an object >>> a = [1,2,3] d) examine the object >>> dir(a) ['__add__', '__class__', '__contains__', '__delattr__', '__delitem__', '__delslice__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__getitem__', '__getslice__', '__gt__', '__hash__', '__iadd__', '__imul__', '__init__', '__iter__', '__le__', '__len__', '__lt__', '__mul__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__reversed__', '__rmul__', '__setattr__', '__setitem__', '__setslice__', '__sizeof__', '__str__', '__subclasshook__', 'append', 'count', 'extend', 'index', 'insert', 'pop', 'remove', 'reverse', 'sort'] e) get the help on this object >>> help(a) Help on list object: class list(object) | list() -> new list | list(sequence) -> new list initialized from sequence's items | | Methods defined here: | | __add__(...) | x.__add__(y) <==> x+y f) get help on a method: >>> help(a.pop) Help on built-in function pop: pop(...) L.pop([index]) -> item -- remove and return item at index (default last). Raises IndexError if list is empty or index is out of range. This is amazingly useful. Is there anyway to have a similar experience in the erlang shell? From icfp.publicity@REDACTED Tue May 10 10:10:26 2011 From: icfp.publicity@REDACTED (Wouter Swierstra) Date: Tue, 10 May 2011 10:10:26 +0200 Subject: [erlang-questions] An update on ICFP'11 in Tokyo (September 18-24, 2011) Message-ID: Given the fairly recent severe earthquake and tsunami in Japan, you may wonder how this affects the preparations for ICFP'11 in Tokyo. Luckily, Tokyo was significantly less affected by these saddening events than the regions further north. In fact, the situation in Tokyo is almost back to normal, after only two months, with another four months until ICFP. Moreover, all major embassies have in the meantime lifted their travel advisories for the Tokyo metropolitan region (while they still maintain active advisories for some other regions.) Our local organisational team has completed major parts of the preparations and recently summarised the most important facts on a local information page for ICFP'11: http://www.biglab.org/icfp11local/index.html The main conference site is at http://www.icfpconference.org/icfp2011/ We are looking forward to seeing you in Tokyo in September! Manuel Chakravarty Zhenjiang Hu (General Chairs of ICFP'11) From the.malkolm@REDACTED Tue May 10 13:28:03 2011 From: the.malkolm@REDACTED (Alexander Krasnukhin) Date: Tue, 10 May 2011 13:28:03 +0200 Subject: [erlang-questions] Erlang proccess memory usage In-Reply-To: References: Message-ID: Hej, You could try to change the default heap size. This extra information could help you to solve this mystery with memory usage. If making heap size bigger x2 won't affect used memory - the problem is elsewhere. -- Regards, Alexander -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jouni.Ryno@REDACTED Tue May 10 14:22:42 2011 From: Jouni.Ryno@REDACTED (Jouni =?ISO-8859-1?Q?Ryn=F6?=) Date: Tue, 10 May 2011 15:22:42 +0300 Subject: [erlang-questions] Erlang cross compilation for MOXA arm9, problems ... Message-ID: <1305030162.4012.18.camel@adic> I'm trying to cross compile Erlang to arm9: root@REDACTED:/mnt/sd/arm-moxa-linux-gnu# cat /proc/cpuinfo Processor : ARM922Tid(wb) rev 1 (v4l) compilation goes fine, but any try to run the tools fails with the following error message: root@REDACTED:/mnt/sd/arm-moxa-linux-gnu# ./bin/erl Failed to set thread main status: Invalid argument (22) Aborted Does that ring any bells for possible reasons? (I did follow the source code to where it happens, but from there it will jump to into the mysterious world of thread libraries ...) Thanks, Jouni -- Jouni Ryn? mailto://Jouni.Ryno@REDACTED/ http://www.geo.fmi.fi/~ryno/ Finnish Meteorological Institute http://www.fmi.fi/ Observation services http://www.geo.fmi.fi/ P.O.BOX 503 Tel (+358)-9-19294656 FI-00101 Helsinki FAX (+358)-9-19294603 Finland priv-GSM (+358)-50-5302903 "It's just zeros and ones, it cannot be hard" From alexey.v.romanov@REDACTED Tue May 10 14:49:52 2011 From: alexey.v.romanov@REDACTED (Alexey Romanov) Date: Tue, 10 May 2011 16:49:52 +0400 Subject: [erlang-questions] Possible documentation bug in httpc Message-ID: Comparing https://github.com/erlang/otp/blob/dev/lib/inets/src/http_client/httpc.erl#L486 and documentation for `stream` option at http://www.erlang.org/doc/man/httpc.html#request-5 it seems that {http, {RequestId, {error, Reason}}} is missing as a possible message sent to the calling process. Is this correct? Yours, Alexey Romanov From ivan@REDACTED Tue May 10 14:50:35 2011 From: ivan@REDACTED (Ivan Uemlianin) Date: Tue, 10 May 2011 13:50:35 +0100 Subject: [erlang-questions] SOLVED: Re: Appmon, pman on MacOSX In-Reply-To: <4DC80FDC.5010102@llaisdy.com> References: <4DC80FDC.5010102@llaisdy.com> Message-ID: <4DC9349B.9060408@llaisdy.com> Dear All Thanks to everybody for guidance. I have appmon and pman working now (although I haven't done anything with them yet). Essentially I uninstalled tcl and tk from my MacPorts (this involved some fiddling around). There is another wish on my system, in /sw/bin/wish Presumably this was from fink. Anyway, it works. Forgive me if I'm less than enthusiastic about Homebrew. I'm sure it's very nice. These days I just install everything from source. Best wishes Ivan On 09/05/2011 17:01, Ivan Uemlianin wrote: > Dear All > > I'm running erlang R13B01 on MacOSX.6. I've just tried to launch appmon > from the erlang shell and got this error (and no appmon): > > dyld: Library not loaded: /opt/local/lib/libX11.6.dylib > Referenced from: /opt/local/bin/wish8.5 > Reason: no suitable image found. Did find: > /opt/local/lib/libX11.6.dylib: mach-o, but wrong architecture > > I've done a quick google but found nothing, so I'm about to go deeper. > > In the meantime, has anybody else come up against this and found out how > to fix it? > > With thanks and best wishes > > Ivan > > -- ============================================================ Ivan A. Uemlianin Speech Technology Research and Development ivan@REDACTED www.llaisdy.com llaisdy.wordpress.com www.linkedin.com/in/ivanuemlianin "Froh, froh! Wie seine Sonnen, seine Sonnen fliegen" (Schiller, Beethoven) ============================================================ From matthias@REDACTED Tue May 10 15:22:48 2011 From: matthias@REDACTED (Matthias Lang) Date: Tue, 10 May 2011 15:22:48 +0200 Subject: [erlang-questions] Erlang cross compilation for MOXA arm9, problems ... In-Reply-To: <1305030162.4012.18.camel@adic> References: <1305030162.4012.18.camel@adic> Message-ID: <20110510132248.GA3221@corelatus.se> Hi, > root@REDACTED:/mnt/sd/arm-moxa-linux-gnu# cat /proc/cpuinfo > Processor : ARM922Tid(wb) rev 1 (v4l) > root@REDACTED:/mnt/sd/arm-moxa-linux-gnu# ./bin/erl > Failed to set thread main status: Invalid argument (22) > Aborted > > Does that ring any bells for possible reasons? Don't think I've seen that problem before. FWIW, I run Erlang cross-compiled for Processor : ARM926EJ-S rev 5 (v5l) I don't know how close an ARM926EJ-S is to an ARM922Tid(wb). I'm using using the ELDK toolchain from denx.de (gcc 4.2.2). Matt From ds.erl@REDACTED Tue May 10 15:22:01 2011 From: ds.erl@REDACTED (DS) Date: Tue, 10 May 2011 15:22:01 +0200 Subject: [erlang-questions] Erlang cross compilation for MOXA arm9, problems ... In-Reply-To: <1305030162.4012.18.camel@adic> References: <1305030162.4012.18.camel@adic> Message-ID: <6E651619-8C97-4DDC-9834-EEE3EA62831C@sol42.com> On 10 May 2011, at 14:22, Jouni Ryn? wrote: > root@REDACTED:/mnt/sd/arm-moxa-linux-gnu# ./bin/erl > Failed to set thread main status: Invalid argument (22) > Aborted > Does that ring any bells for possible reasons? It rings one for me, also pthread-related but on a different architecture (Irix). The problem was with "system scope" pthreads and non-root users, and I solved it by avoiding the call to pthread_attr_setscope() in erts/lib_src/pthread/ethread.c:206. I've also run Erlang on ARM v5l without problems, but I did all of that as root. > (I did follow the source code to where it happens, but from there it > will jump to into the mysterious world of thread libraries ...) I'm too lazy to (download, unzip and) grep the emulator sources for "Failed to set thread main status", so it would help if you said what C function contains "there". Regards. -Daniel From dmercer@REDACTED Tue May 10 16:13:21 2011 From: dmercer@REDACTED (David Mercer) Date: Tue, 10 May 2011 09:13:21 -0500 Subject: [erlang-questions] byte() vs. char() use in documentation In-Reply-To: <974410F2-973C-419E-B387-35D764A636B4@cs.otago.ac.nz> References: <20110502091415.GA6512@erix.ericsson.se> <20110503094549.GA10981@erix.ericsson.se> <201105040533.58985.als@iinet.net.au> <20110504075734.GA16456@erix.ericsson.se> <294BF31C-A04F-49C1-8CCB-E168D5AFAE5B@cs.otago.ac.nz> <60C82374-90CF-4200-9F87-1B662173A4B1@masklinn.net> <0E4AB3DB-3830-40C8-BA3F-7AACF548C6F5@cs.otago.ac.nz> <8B8AEC02-8555-4BC6-BE3D-E1A35E9057C1@masklinn.net> <974410F2-973C-419E-B387-35D764A636B4@cs.otago.ac.nz> Message-ID: <00a801cc0f1c$6c81d250$458576f0$@com> On Monday, May 09, 2011, Richard O'Keefe wrote: > For *programmers*, I don't see "one thing defined in Unicode = > one thing manipulated in the program" as particularly confusing; > anything else (such as grapheme clusters) would confuse *me* a > great deal more. That right there is the crux of my position. Unicode may or may not be a perfect representation of all the characters and strings and phrases and i18n stuff I want to do, but it's something I understand and can work with. For my purposes and applications, Unicode is fine. I've asked for an example where it does not work, where it breaks down, and the only one I've heard is if I were programming a word processor in Erlang. While this might be a valid application for Erlang, it's not the kind of thing I myself work on and can relate to. In my mind, I would have imagined word processors as having to do all sorts of specialized stuff regarding characters and how they look. For example, I would expect a word processor to match "na?ve" when I do a search on "naive", just because "i" and "?" look similar, and "i" is easier to type. So therefore, I'd expect word processors to do lots of specialized string manipulation and matching that I usually don't have to be concerned with. Most programmers just want a way to represent foreign-looking strings. Unicode is the standard for this sort of thing, and Unicode's basic element is the codepoint, so I guess I'd expect Erlang to represent strings as lists of Unicode codepoints. Not grapheme clusters (sounds like something to do with buckyballs), and not some specialized encoding of Unicode, like UTF-8. "?" is Unicode codepoint 239 (or 16#EF), not the UTF-8 encoding of that. > At least if people deal with the things that are > defined by Unicode they can appeal to the Unicode standard itself > for help. From ivan@REDACTED Tue May 10 16:15:03 2011 From: ivan@REDACTED (Ivan Uemlianin) Date: Tue, 10 May 2011 15:15:03 +0100 Subject: [erlang-questions] SOLVED: Re: Appmon over ssh In-Reply-To: References: Message-ID: <4DC94867.2030105@llaisdy.com> Dear Ahmed & Attila Thanks for your guidance. I'm going for option #2, but there are some firewall hurdles in the way (I'll post separately). Best wishes Ivan On 09/05/2011 18:46, Ivan Uemlianin wrote: > Dear all > > I have an erlang app on a remote server that I'd like to monitor with appmon and pman. How can I do that? Can I do either of these: > > 1. use some ssh incantation to run appmon on the remote machine but have the GUI appear locally (and would this work if my local tcl is broken, which it is currently). > > 2. add my machine as a node to the remote machine and then run appmon locally to view the remote app. > > With thanks and best wishes > > Ivan > > Sent from iPhone. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- ============================================================ Ivan A. Uemlianin Speech Technology Research and Development ivan@REDACTED www.llaisdy.com llaisdy.wordpress.com www.linkedin.com/in/ivanuemlianin "Froh, froh! Wie seine Sonnen, seine Sonnen fliegen" (Schiller, Beethoven) ============================================================ From ivan@REDACTED Tue May 10 16:24:13 2011 From: ivan@REDACTED (Ivan Uemlianin) Date: Tue, 10 May 2011 15:24:13 +0100 Subject: [erlang-questions] how to connect erlang nodes through an uncontrolled firewall Message-ID: <4DC94A8D.6000501@llaisdy.com> Dear All I'd like to connect a couple of erlang nodes together, one "here", one on a remote machine. There are two firewalls in the way: one on the remote machine, one local. The remote firewall I can ask for ports to be opened. I've read that 4369 for epmd and one other port are required (the second can be assigned at runtime using sth like erl -name qweasd -kernel inet_dist_listen_min 9001 inet_dist_listen_max 9001 [1] ). The local firewall is fixed, in the sense that I don't think I can ask for ports to be opened and so on (I'm in a shared office building with provided internet access). Is there anything I can do at this end to open a connection? I can ssh out the the remote machine. Can I have the nodes connect over ssh? With thanks and best wishes Ivan [1] http://stackoverflow.com/questions/2369341/which-tcp-port-does-erlang-use-for-connecting-to-a-remote-node -- ============================================================ Ivan A. Uemlianin Speech Technology Research and Development ivan@REDACTED www.llaisdy.com llaisdy.wordpress.com www.linkedin.com/in/ivanuemlianin "Froh, froh! Wie seine Sonnen, seine Sonnen fliegen" (Schiller, Beethoven) ============================================================ From zerthurd@REDACTED Tue May 10 20:28:44 2011 From: zerthurd@REDACTED (Maxim Treskin) Date: Wed, 11 May 2011 01:28:44 +0700 Subject: [erlang-questions] [ANN] mctrace-0.2 release: tracing tool with user-defined hooks Message-ID: Hello Mctrace is debugging tool for tracing messages. It injects in gen_server or gen_fsm behaviored module at compile-time via parse_transform. Features: * support of gen_server and gen_fsm behaviours (arbitrary behaviours planned) * send, receive, procs and timestamp options of erlang:trace/3 supported * easy to switch on/off by compiler option * rebarized * examples included Check the project page: https://github.com/metachord/mctrace Feedback is welcome! -- Maxim Treskin -------------- next part -------------- An HTML attachment was scrubbed... URL: From vances@REDACTED Tue May 10 20:37:25 2011 From: vances@REDACTED (Vance Shipley) Date: Tue, 10 May 2011 22:37:25 +0400 Subject: [erlang-questions] SOLVED: Re: Appmon, pman on MacOSX In-Reply-To: <4DC9349B.9060408@llaisdy.com> References: <4DC80FDC.5010102@llaisdy.com> <4DC9349B.9060408@llaisdy.com> Message-ID: <20110510183724.GB30717@aluminum-2.local> You should try using the `aqua' variant of tk which doesn't use X11 at all. I found I also needed the `threads' variant of tcl. On Tue, May 10, 2011 at 01:50:35PM +0100, Ivan Uemlianin wrote: } Thanks to everybody for guidance. I have appmon and pman working } now (although I haven't done anything with them yet). -- -Vance From stu.bailey@REDACTED Tue May 10 20:52:20 2011 From: stu.bailey@REDACTED (Stu Bailey) Date: Tue, 10 May 2011 11:52:20 -0700 Subject: [erlang-questions] Erlang Opportunities Message-ID: My company is hiring erlang developers. Where is the best place to post Erlang job opportunities? From mjtruog@REDACTED Tue May 10 20:56:50 2011 From: mjtruog@REDACTED (Michael Truog) Date: Tue, 10 May 2011 11:56:50 -0700 Subject: [erlang-questions] Erlang Opportunities In-Reply-To: References: Message-ID: <4DC98A72.9070100@gmail.com> http://totally-erlang.com/ On 05/10/2011 11:52 AM, Stu Bailey wrote: > My company is hiring erlang developers. Where is the best place to > post Erlang job opportunities? > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From stu.bailey@REDACTED Tue May 10 20:59:02 2011 From: stu.bailey@REDACTED (Stu Bailey) Date: Tue, 10 May 2011 11:59:02 -0700 Subject: [erlang-questions] Erlang Opportunities In-Reply-To: <4DC98A72.9070100@gmail.com> References: <4DC98A72.9070100@gmail.com> Message-ID: Many thanks everyone! On Tue, May 10, 2011 at 11:56 AM, Michael Truog wrote: > http://totally-erlang.com/ > > On 05/10/2011 11:52 AM, Stu Bailey wrote: >> My company is hiring erlang developers. ?Where is the best place to >> post Erlang job opportunities? >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > From spawn.think@REDACTED Tue May 10 21:24:57 2011 From: spawn.think@REDACTED (Ahmed Omar) Date: Tue, 10 May 2011 21:24:57 +0200 Subject: [erlang-questions] Erlang Opportunities In-Reply-To: References: <4DC98A72.9070100@gmail.com> Message-ID: Erlang/OTP professionals group on LinkedIn http://www.linkedin.com/groups?careerDiscussion=&gid=90878 On Tue, May 10, 2011 at 8:59 PM, Stu Bailey wrote: > Many thanks everyone! > > > On Tue, May 10, 2011 at 11:56 AM, Michael Truog wrote: > > http://totally-erlang.com/ > > > > On 05/10/2011 11:52 AM, Stu Bailey wrote: > >> My company is hiring erlang developers. Where is the best place to > >> post Erlang job opportunities? > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questions@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-questions > >> > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think -------------- next part -------------- An HTML attachment was scrubbed... URL: From mihai@REDACTED Tue May 10 21:54:42 2011 From: mihai@REDACTED (Mihai Balea) Date: Tue, 10 May 2011 15:54:42 -0400 Subject: [erlang-questions] Erlang Opportunities In-Reply-To: References: <4DC98A72.9070100@gmail.com> Message-ID: <6FFBFBCA-4EEC-4F46-8E8C-0C922DEC1A4B@hates.ms> These two places are probably your best options. Some people post job openings to this mailing list as well. On May 10, 2011, at 3:24 PM, Ahmed Omar wrote: > Erlang/OTP professionals group on LinkedIn > http://www.linkedin.com/groups?careerDiscussion=&gid=90878 > > On Tue, May 10, 2011 at 8:59 PM, Stu Bailey wrote: > Many thanks everyone! > > > On Tue, May 10, 2011 at 11:56 AM, Michael Truog wrote: > > http://totally-erlang.com/ > > > > On 05/10/2011 11:52 AM, Stu Bailey wrote: > >> My company is hiring erlang developers. Where is the best place to > >> post Erlang job opportunities? > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questions@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-questions > >> > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > -- > Best Regards, > - Ahmed Omar > http://nl.linkedin.com/in/adiaa > Follow me on twitter > @spawn_think > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.goertzen@REDACTED Tue May 10 21:57:45 2011 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Tue, 10 May 2011 14:57:45 -0500 Subject: [erlang-questions] detecting ssh auth failures Message-ID: I am using ssh to automatically connect and operate a remote device. I'd like to distinguish authentication failures from other kinds of failures. Currently I will get this as an auth failure from ssh:connect(): {error,"Unable to connect using the available authentication methods"} Now I could include that error string in a pattern to detect an auth failure, but it feels rather brittle (ie, what if someone changes the wording). Is there a better way to do it? Is this an API design bug? Regards, Dan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From freza@REDACTED Tue May 10 22:45:57 2011 From: freza@REDACTED (Jachym Holecek) Date: Tue, 10 May 2011 21:45:57 +0100 Subject: [erlang-questions] how to connect erlang nodes through an uncontrolled firewall In-Reply-To: <4DC94A8D.6000501@llaisdy.com> References: <4DC94A8D.6000501@llaisdy.com> Message-ID: <20110510204557.GA830@hanele.lan> # Ivan Uemlianin 2011-05-10: > I'd like to connect a couple of erlang nodes together, one "here", one > on a remote machine. There are two firewalls in the way: one on the > remote machine, one local. > > The remote firewall I can ask for ports to be opened. I've read that > 4369 for epmd and one other port are required (the second can be > assigned at runtime using sth like > > erl -name qweasd -kernel inet_dist_listen_min 9001 > inet_dist_listen_max 9001 [1] > > The local firewall is fixed, in the sense that I don't think I can ask > for ports to be opened and so on (I'm in a shared office building with > provided internet access). > > Is there anything I can do at this end to open a connection? I can ssh > out the the remote machine. Can I have the nodes connect over ssh? You can forward arbitrary ports via 'ssh -L ...' -- never tried that for Erlang distribution though, so just a pointer for experiment really. If you have sufficient control over the remote server, openvpn is another quite hassle-free option for you. HTH, -- Jachym From comptekki@REDACTED Tue May 10 23:36:19 2011 From: comptekki@REDACTED (Wes James) Date: Tue, 10 May 2011 15:36:19 -0600 Subject: [erlang-questions] macro in include definition - can't Message-ID: I was trying to do something like this: -include("some.hrl"). -include(?FILE). Where FILE is defined in some.hrl, but found that can't be done. I was trying to define a path to a hrl file without having it show in the actual file on github. I guess the way to do this is with an environment variable, if I'm worried about it. I found info on macros in "The Preprocessor" page on erlang.org http://www.erlang.org/doc/reference_manual/macros.html -wes From spawn.think@REDACTED Wed May 11 00:33:31 2011 From: spawn.think@REDACTED (Ahmed Omar) Date: Wed, 11 May 2011 00:33:31 +0200 Subject: [erlang-questions] macro in include definition - can't In-Reply-To: References: Message-ID: I'm not sure i understand what u r trying to do exactly. but are u trying to do -define(FILE, "somepath"). in some.hrl? cause ?FILE is a predefined macro that is expanded to the name of the current module, you can't redefine it. On Tue, May 10, 2011 at 11:36 PM, Wes James wrote: > I was trying to do something like this: > > -include("some.hrl"). > -include(?FILE). > > Where FILE is defined in some.hrl, but found that can't be done. I > was trying to define a path to a hrl file without having it show in > the actual file on github. I guess the way to do this is with an > environment variable, if I'm worried about it. > > I found info on macros in "The Preprocessor" page on erlang.org > > http://www.erlang.org/doc/reference_manual/macros.html > > -wes > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think -------------- next part -------------- An HTML attachment was scrubbed... URL: From comptekki@REDACTED Wed May 11 16:06:02 2011 From: comptekki@REDACTED (Wes James) Date: Wed, 11 May 2011 08:06:02 -0600 Subject: [erlang-questions] macro in include definition - can't In-Reply-To: References: Message-ID: I have a file pcount.erl and pcount.hrl pcount.hrl On Tue, May 10, 2011 at 4:33 PM, Ahmed Omar wrote: > I'm not sure i understand what u r trying to do exactly. but are u trying to > do > -define(FILE, "somepath"). > in some.hrl? > cause ?FILE is a predefined macro that is expanded to the name of the > current module, you can't redefine it. > > On Tue, May 10, 2011 at 11:36 PM, Wes James wrote: >> >> I was trying to do something like this: >> >> -include("some.hrl"). >> -include(?FILE). >> >> Where FILE is defined in some.hrl, but found that can't be done. ? I >> was trying to define a path to a hrl file without having it show in >> the actual file on github. ?I guess the way to do this is with an >> environment variable, if I'm worried about it. >> >> I found info on macros in "The Preprocessor" page on erlang.org >> >> http://www.erlang.org/doc/reference_manual/macros.html >> >> -wes >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > > > -- > Best Regards, > - Ahmed Omar > http://nl.linkedin.com/in/adiaa > Follow me on twitter > @spawn_think > From comptekki@REDACTED Wed May 11 16:12:33 2011 From: comptekki@REDACTED (Wes James) Date: Wed, 11 May 2011 08:12:33 -0600 Subject: [erlang-questions] macro in include definition - can't In-Reply-To: References: Message-ID: oops, clicked send to soon: I have pcount.erl and pcount.hrl here is part of pcount.hrl -define(SOME, "/some/path/some.hrl"). in pcount.erl -include("pcount.hrl"). -include(?SOME). erlc pcount.erl ./pcount.erl:10: badly formed 'include' with -include("?SOME"). I get: erlc pcount.erl ./pcount.erl:10: badly formed 'include' So there doesn't seem to be a way of doing nested macros. thx, -wes On Tue, May 10, 2011 at 4:33 PM, Ahmed Omar wrote: > I'm not sure i understand what u r trying to do exactly. but are u trying to > do > -define(FILE, "somepath"). > in some.hrl? > cause ?FILE is a predefined macro that is expanded to the name of the > current module, you can't redefine it. > > On Tue, May 10, 2011 at 11:36 PM, Wes James wrote: >> >> I was trying to do something like this: >> >> -include("some.hrl"). >> -include(?FILE). >> >> Where FILE is defined in some.hrl, but found that can't be done. ? I >> was trying to define a path to a hrl file without having it show in >> the actual file on github. ?I guess the way to do this is with an >> environment variable, if I'm worried about it. >> >> I found info on macros in "The Preprocessor" page on erlang.org >> >> http://www.erlang.org/doc/reference_manual/macros.html >> >> -wes >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > > > -- > Best Regards, > - Ahmed Omar > http://nl.linkedin.com/in/adiaa > Follow me on twitter > @spawn_think > From spawn.think@REDACTED Wed May 11 16:52:44 2011 From: spawn.think@REDACTED (Ahmed Omar) Date: Wed, 11 May 2011 16:52:44 +0200 Subject: [erlang-questions] macro in include definition - can't In-Reply-To: References: Message-ID: But why are you doing it that way? Why not just in pcount.hrl write include("/some/path/some.hrl"). and in you pcount.erl just -include("pcount.hrl"). On Wed, May 11, 2011 at 4:12 PM, Wes James wrote: > oops, clicked send to soon: > > I have pcount.erl and pcount.hrl > > here is part of pcount.hrl > > -define(SOME, "/some/path/some.hrl"). > > in pcount.erl > > -include("pcount.hrl"). > -include(?SOME). > > erlc pcount.erl > ./pcount.erl:10: badly formed 'include' > > with > > -include("?SOME"). > > I get: > > erlc pcount.erl > ./pcount.erl:10: badly formed 'include' > > So there doesn't seem to be a way of doing nested macros. > > thx, > > -wes > On Tue, May 10, 2011 at 4:33 PM, Ahmed Omar wrote: > > I'm not sure i understand what u r trying to do exactly. but are u trying > to > > do > > -define(FILE, "somepath"). > > in some.hrl? > > cause ?FILE is a predefined macro that is expanded to the name of the > > current module, you can't redefine it. > > > > On Tue, May 10, 2011 at 11:36 PM, Wes James wrote: > >> > >> I was trying to do something like this: > >> > >> -include("some.hrl"). > >> -include(?FILE). > >> > >> Where FILE is defined in some.hrl, but found that can't be done. I > >> was trying to define a path to a hrl file without having it show in > >> the actual file on github. I guess the way to do this is with an > >> environment variable, if I'm worried about it. > >> > >> I found info on macros in "The Preprocessor" page on erlang.org > >> > >> http://www.erlang.org/doc/reference_manual/macros.html > >> > >> -wes > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questions@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > > -- > > Best Regards, > > - Ahmed Omar > > http://nl.linkedin.com/in/adiaa > > Follow me on twitter > > @spawn_think > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think -------------- next part -------------- An HTML attachment was scrubbed... URL: From spawn.think@REDACTED Wed May 11 16:53:19 2011 From: spawn.think@REDACTED (Ahmed Omar) Date: Wed, 11 May 2011 16:53:19 +0200 Subject: [erlang-questions] macro in include definition - can't In-Reply-To: References: Message-ID: of course the first one is -include("/some/path/some.hrl"). On Wed, May 11, 2011 at 4:52 PM, Ahmed Omar wrote: > But why are you doing it that way? > Why not just in pcount.hrl write > include("/some/path/some.hrl"). > > and in you pcount.erl just > -include("pcount.hrl"). > > > > On Wed, May 11, 2011 at 4:12 PM, Wes James wrote: > >> oops, clicked send to soon: >> >> I have pcount.erl and pcount.hrl >> >> here is part of pcount.hrl >> >> -define(SOME, "/some/path/some.hrl"). >> >> in pcount.erl >> >> -include("pcount.hrl"). >> -include(?SOME). >> >> erlc pcount.erl >> ./pcount.erl:10: badly formed 'include' >> >> with >> >> -include("?SOME"). >> >> I get: >> >> erlc pcount.erl >> ./pcount.erl:10: badly formed 'include' >> >> So there doesn't seem to be a way of doing nested macros. >> >> thx, >> >> -wes >> On Tue, May 10, 2011 at 4:33 PM, Ahmed Omar >> wrote: >> > I'm not sure i understand what u r trying to do exactly. but are u >> trying to >> > do >> > -define(FILE, "somepath"). >> > in some.hrl? >> > cause ?FILE is a predefined macro that is expanded to the name of the >> > current module, you can't redefine it. >> > >> > On Tue, May 10, 2011 at 11:36 PM, Wes James >> wrote: >> >> >> >> I was trying to do something like this: >> >> >> >> -include("some.hrl"). >> >> -include(?FILE). >> >> >> >> Where FILE is defined in some.hrl, but found that can't be done. I >> >> was trying to define a path to a hrl file without having it show in >> >> the actual file on github. I guess the way to do this is with an >> >> environment variable, if I'm worried about it. >> >> >> >> I found info on macros in "The Preprocessor" page on erlang.org >> >> >> >> http://www.erlang.org/doc/reference_manual/macros.html >> >> >> >> -wes >> >> _______________________________________________ >> >> erlang-questions mailing list >> >> erlang-questions@REDACTED >> >> http://erlang.org/mailman/listinfo/erlang-questions >> > >> > >> > >> > -- >> > Best Regards, >> > - Ahmed Omar >> > http://nl.linkedin.com/in/adiaa >> > Follow me on twitter >> > @spawn_think >> > >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > > > -- > Best Regards, > - Ahmed Omar > http://nl.linkedin.com/in/adiaa > Follow me on twitter > @spawn_think > > -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think -------------- next part -------------- An HTML attachment was scrubbed... URL: From comptekki@REDACTED Wed May 11 17:14:05 2011 From: comptekki@REDACTED (Wes James) Date: Wed, 11 May 2011 09:14:05 -0600 Subject: [erlang-questions] macro in include definition - can't In-Reply-To: References: Message-ID: Good point. -wes On Wed, May 11, 2011 at 8:52 AM, Ahmed Omar wrote: > But why are you doing it that way? > Why not just in pcount.hrl write > include("/some/path/some.hrl"). > > and in you pcount.erl just > -include("pcount.hrl"). > > > On Wed, May 11, 2011 at 4:12 PM, Wes James wrote: >> >> oops, clicked send to soon: >> >> I have pcount.erl and pcount.hrl >> >> here is part of pcount.hrl >> >> -define(SOME, "/some/path/some.hrl"). >> >> in pcount.erl >> >> -include("pcount.hrl"). >> -include(?SOME). >> >> erlc pcount.erl >> ./pcount.erl:10: badly formed 'include' >> >> with >> >> -include("?SOME"). >> >> I get: >> >> erlc pcount.erl >> ./pcount.erl:10: badly formed 'include' >> >> So there doesn't seem to be a way of doing nested macros. >> >> thx, >> >> -wes >> On Tue, May 10, 2011 at 4:33 PM, Ahmed Omar wrote: >> > I'm not sure i understand what u r trying to do exactly. but are u >> > trying to >> > do >> > -define(FILE, "somepath"). >> > in some.hrl? >> > cause ?FILE is a predefined macro that is expanded to the name of the >> > current module, you can't redefine it. >> > >> > On Tue, May 10, 2011 at 11:36 PM, Wes James wrote: >> >> >> >> I was trying to do something like this: >> >> >> >> -include("some.hrl"). >> >> -include(?FILE). >> >> >> >> Where FILE is defined in some.hrl, but found that can't be done. ? I >> >> was trying to define a path to a hrl file without having it show in >> >> the actual file on github. ?I guess the way to do this is with an >> >> environment variable, if I'm worried about it. >> >> >> >> I found info on macros in "The Preprocessor" page on erlang.org >> >> >> >> http://www.erlang.org/doc/reference_manual/macros.html >> >> >> >> -wes >> >> _______________________________________________ >> >> erlang-questions mailing list >> >> erlang-questions@REDACTED >> >> http://erlang.org/mailman/listinfo/erlang-questions >> > >> > >> > >> > -- >> > Best Regards, >> > - Ahmed Omar >> > http://nl.linkedin.com/in/adiaa >> > Follow me on twitter >> > @spawn_think >> > >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > > > -- > Best Regards, > - Ahmed Omar > http://nl.linkedin.com/in/adiaa > Follow me on twitter > @spawn_think > From hknight555@REDACTED Wed May 11 22:22:46 2011 From: hknight555@REDACTED (Hank Knight) Date: Wed, 11 May 2011 17:22:46 -0300 Subject: [erlang-questions] Start erl in daemon mode at boot Message-ID: I am trying to start erl in daemon mode, using the -detached parameter. It runs correctly when initiated from a command line however it fails when initiated using rc.local at boot time. I am running Erlang on Ubuntu. Any ideas on how to get it to run in daemon mode at boot time? Thanks, Hank From comptekki@REDACTED Wed May 11 22:26:13 2011 From: comptekki@REDACTED (Wes James) Date: Wed, 11 May 2011 14:26:13 -0600 Subject: [erlang-questions] Start erl in daemon mode at boot In-Reply-To: References: Message-ID: Does this help any: http://ubuntuforums.org/showthread.php?t=648425 -wes On Wed, May 11, 2011 at 2:22 PM, Hank Knight wrote: > I am trying to start erl in daemon mode, using the -detached parameter. > > It runs correctly when initiated from a command line however it fails > when initiated using rc.local at boot time. > > I am running Erlang on Ubuntu. > > Any ideas on how to get it to run in daemon mode at boot time? > > Thanks, > Hank > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From dzejefkej@REDACTED Thu May 12 03:40:50 2011 From: dzejefkej@REDACTED (=?UTF-8?Q?dzejefkej?=) Date: Thu, 12 May 2011 03:40:50 +0200 Subject: [erlang-questions] =?utf-8?q?how_to_access_process_heap_from_outs?= =?utf-8?q?ide_the_process?= Message-ID: <15485743.41e015f9.4dcb3aa2.ad7f7@o2.pl> hi, I need to sniff state of the process. It is gen_srv or gen_fsm executing synchronous call, so it ignores sys:get_status/1 or /2. process_info is also not very helpful. What is the simplest way to access StateData or dump and decode the heap? regards, D From rapsey@REDACTED Thu May 12 08:54:30 2011 From: rapsey@REDACTED (Rapsey) Date: Thu, 12 May 2011 08:54:30 +0200 Subject: [erlang-questions] Start erl in daemon mode at boot In-Reply-To: References: Message-ID: My current way to run erlang as daemon in ubuntu: Script that executes erlang itself with my app: #!/bin/sh cd /path/to/ebin erl +Bd +P 1000000 -env ERL_MAX_PORTS 100000 +K true +A 32 -mnesia dir '"/path/to/mnesia"' -eval "myapp:start()" Upstart file. Placed in /etc/init/nameofapp.conf. It runs erlang through dtach, which allows me to enter the console at any time and pipes outout to a logfile. To attach to erlang simply run: dtach -a /tmp/erl There is one problem with this setup. sudo stop name_of_app does not work. It will remove the job, but erlang won't actually be killed. If I want to turn the daemon off, I have to go to erl console through dtach and execute q(). start on filesystem and net-device-up stop on runlevel [06] env HOME=/home/ubuntu respawn console output script exec start-stop-daemon --name NAME_OF_INSTANCE --start --chuid USER_TO_RUN_AS --exec /usr/bin/dtach -- -c /tmp/erl /PATH/TO/SCRIPT > /var/log/erl.log end script Sergej On Wed, May 11, 2011 at 10:26 PM, Wes James wrote: > Does this help any: > > http://ubuntuforums.org/showthread.php?t=648425 > > -wes > > On Wed, May 11, 2011 at 2:22 PM, Hank Knight wrote: > > I am trying to start erl in daemon mode, using the -detached parameter. > > > > It runs correctly when initiated from a command line however it fails > > when initiated using rc.local at boot time. > > > > I am running Erlang on Ubuntu. > > > > Any ideas on how to get it to run in daemon mode at boot time? > > > > Thanks, > > Hank > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paolo.negri@REDACTED Thu May 12 12:10:49 2011 From: paolo.negri@REDACTED (Paolo Negri) Date: Thu, 12 May 2011 12:10:49 +0200 Subject: [erlang-questions] erlang bignums implementation Message-ID: Dear list I was pleased to find out that the following in erlang just works fine Eshell V5.8.3 (abort with ^G) 1> 1 bsl 70. 1180591620717411303424 I'm then evaluating to use bitwise operations on bignums (up to 128 bits) and I'm asking if anyone can share how internally bignums are represented what's the overhead of using them and if there are any caveats related to their usage. Thanks, Paolo Negri From steven.charles.davis@REDACTED Thu May 12 12:38:10 2011 From: steven.charles.davis@REDACTED (Steve Davis) Date: Thu, 12 May 2011 03:38:10 -0700 (PDT) Subject: [erlang-questions] erlang bignums implementation In-Reply-To: References: Message-ID: <5912c5b4-fed2-4286-aa54-e402bee48c44@v31g2000vbs.googlegroups.com> As far as overhead, this may help: http://www.erlang.org/doc/efficiency_guide/advanced.html#id66649 Caveats? None that I am personally aware of. Others may be able to say more. /s On May 12, 5:10?am, Paolo Negri wrote: > Dear list > > I was pleased to find out that the following in erlang just works fine > > Eshell V5.8.3 ?(abort with ^G) > 1> 1 bsl 70. > 1180591620717411303424 > > I'm then evaluating to use bitwise operations on bignums (up to 128 > bits) and I'm asking if anyone can share how internally bignums are > represented what's the overhead of using them and if there are any > caveats related to their usage. > > Thanks, > > Paolo Negri > _______________________________________________ > erlang-questions mailing list > erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions From bengt.kleberg@REDACTED Thu May 12 14:53:59 2011 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Thu, 12 May 2011 14:53:59 +0200 Subject: [erlang-questions] beginner: How to make dialyzer display the place where "unknown functions" are called Message-ID: <1305204839.22885.7.camel@seasc1137> Greetings, When running dialyzer I get a long list of unknown functions. Is there a way to persuade dialyzer to display which modules that call these unknown functions? This would allow me to stop running xref. bengt From robert.virding@REDACTED Thu May 12 14:55:03 2011 From: robert.virding@REDACTED (Robert Virding) Date: Thu, 12 May 2011 12:55:03 +0000 (GMT) Subject: [erlang-questions] erlang bignums implementation In-Reply-To: <5912c5b4-fed2-4286-aa54-e402bee48c44@v31g2000vbs.googlegroups.com> Message-ID: <1303757678.172901305204903588.JavaMail.root@zimbra> One thing to be aware of is that bsr is an arithmetic shift, both for normal integers and bignums. Robert ----- "Steve Davis" wrote: > As far as overhead, this may help: > > http://www.erlang.org/doc/efficiency_guide/advanced.html#id66649 > > Caveats? None that I am personally aware of. Others may be able to > say > more. > > /s > > On May 12, 5:10?am, Paolo Negri wrote: > > Dear list > > > > I was pleased to find out that the following in erlang just works > fine > > > > Eshell V5.8.3 ?(abort with ^G) > > 1> 1 bsl 70. > > 1180591620717411303424 > > > > I'm then evaluating to use bitwise operations on bignums (up to 128 > > bits) and I'm asking if anyone can share how internally bignums are > > represented what's the overhead of using them and if there are any > > caveats related to their usage. > > > > Thanks, > > > > Paolo Negri > > _______________________________________________ > > erlang-questions mailing list > > > erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From kostis@REDACTED Thu May 12 15:00:35 2011 From: kostis@REDACTED (Kostis Sagonas) Date: Thu, 12 May 2011 16:00:35 +0300 Subject: [erlang-questions] beginner: How to make dialyzer display the place where "unknown functions" are called In-Reply-To: <1305204839.22885.7.camel@seasc1137> References: <1305204839.22885.7.camel@seasc1137> Message-ID: <4DCBD9F3.5070009@cs.ntua.gr> Bengt Kleberg wrote: > Greetings, > > When running dialyzer I get a long list of unknown functions. Is there a > way to persuade dialyzer to display which modules that call these > unknown functions? Nope. What dialyzer is telling you is that perhaps its analysis may able to find more discrepancies in your code base if you include (the modules of) these functions either in the PLT or in the list of files/apps to analyse. That these functions are unknown forces dialyzer to assume that they can accept any argument and return any result. Thus, its analysis may not be as strong as it can be. > This would allow me to stop running xref. Well, there is also 'grep' that can come in handy in a task as trivial as that... Kostis From robert.virding@REDACTED Thu May 12 15:05:22 2011 From: robert.virding@REDACTED (Robert Virding) Date: Thu, 12 May 2011 13:05:22 +0000 (GMT) Subject: [erlang-questions] Reltool, system crashes and ports Message-ID: <500771952.173021305205522337.JavaMail.root@zimbra> I was testing reltool the other day. I opened up the window and was moving apps around, then I closed the window. And the beam crashed with "Bus error"! This happened consistently every time I ran reltool. This started me reflecting on why we originally made it so that ports ran things in other OS processes, and how good a choice this was for reliable systems. Robert P.S. I am running R14B02 on Mac OSX. From antoine.koener@REDACTED Thu May 12 15:06:01 2011 From: antoine.koener@REDACTED (Antoine Koener) Date: Thu, 12 May 2011 15:06:01 +0200 Subject: [erlang-questions] Start erl in daemon mode at boot In-Reply-To: References: Message-ID: <6CDEAF54-EE0A-436B-B989-12AF4AA76F5C@gmail.com> On May 12, 2011, at 08:54 , Rapsey wrote: > My current way to run erlang as daemon in ubuntu: > > Script that executes erlang itself with my app: > #!/bin/sh > cd /path/to/ebin > erl +Bd +P 1000000 -env ERL_MAX_PORTS 100000 +K true +A 32 -mnesia > dir '"/path/to/mnesia"' -eval "myapp:start()" > > > Upstart file. Placed in /etc/init/nameofapp.conf. It runs erlang > through dtach, which allows me to enter the console at any time and > pipes outout to a logfile. To attach to erlang simply run: dtach -a / > tmp/erl > There is one problem with this setup. sudo stop name_of_app does not > work. What about: > #!/bin/sh > cd /path/to/ebin > erl +Bd +P 1000000 -env ERL_MAX_PORTS 100000 +K true +A 32 -mnesia > dir '"/path/to/mnesia"' -eval "myapp:start()" exec erl +Bd +P 1000000 -env ERL_MAX_PORTS 100000 +K true +A 32 - mnesia dir '"/path/to/mnesia"' -eval "myapp:start()" The stop signal will then be received by erl and not /bin/sh > It will remove the job, but erlang won't actually be killed. If I > want to turn the daemon off, I have to go to erl console through > dtach and execute q(). > > start on filesystem and net-device-up > stop on runlevel [06] > > env HOME=/home/ubuntu > respawn > console output > > script > exec start-stop-daemon --name NAME_OF_INSTANCE --start --chuid > USER_TO_RUN_AS --exec /usr/bin/dtach -- -c /tmp/erl /PATH/TO/SCRIPT > > /var/log/erl.log > end script > > > Sergej > > On Wed, May 11, 2011 at 10:26 PM, Wes James > wrote: > Does this help any: > > http://ubuntuforums.org/showthread.php?t=648425 > > -wes > > On Wed, May 11, 2011 at 2:22 PM, Hank Knight > wrote: > > I am trying to start erl in daemon mode, using the -detached > parameter. > > > > It runs correctly when initiated from a command line however it > fails > > when initiated using rc.local at boot time. > > > > I am running Erlang on Ubuntu. > > > > Any ideas on how to get it to run in daemon mode at boot time? > > > > Thanks, > > Hank > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From maruthavanan_s@REDACTED Thu May 12 15:38:13 2011 From: maruthavanan_s@REDACTED (Maruthavanan Subbarayan) Date: Thu, 12 May 2011 09:38:13 -0400 Subject: [erlang-questions] Removing Element from XML Message-ID: Hi, I have a xml document like below 1Erlang
Street 1Country 1
I have done xmerl_scan:stream, now I need to remove the id , name node such that I have only address. How do I remove so that I can below.
Street 1Country 1
Thanks,Marutha -------------- next part -------------- An HTML attachment was scrubbed... URL: From dangud@REDACTED Thu May 12 15:41:56 2011 From: dangud@REDACTED (Dan Gudmundsson) Date: Thu, 12 May 2011 15:41:56 +0200 Subject: [erlang-questions] Reltool, system crashes and ports In-Reply-To: <500771952.173021305205522337.JavaMail.root@zimbra> References: <500771952.173021305205522337.JavaMail.root@zimbra> Message-ID: Well these kind of mails doesn't help make it more stable either, does it. No patch attached and no debug info. And yes wxwidgets is not as stable on mac as the other ports and it's not 100% system independent, so erlang code written on linux don't always work on mac if it is not tested there. And not everyone one of us have macs to test it with, which makes us rely on opensource contributions on platforms not used at Ericsson such as Mac OSX. And I can't test every gui application written with wx. /Dan On Thu, May 12, 2011 at 3:05 PM, Robert Virding wrote: > I was testing reltool the other day. I opened up the window and was moving apps around, then I closed the window. And the beam crashed with "Bus error"! This happened consistently every time I ran reltool. This started me reflecting on why we originally made it so that ports ran things in other OS processes, and how good a choice this was for reliable systems. > > Robert > > P.S. I am running R14B02 on Mac OSX. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From Jouni.Ryno@REDACTED Thu May 12 15:56:00 2011 From: Jouni.Ryno@REDACTED (Jouni =?ISO-8859-1?Q?Ryn=F6?=) Date: Thu, 12 May 2011 16:56:00 +0300 Subject: [erlang-questions] Erlang cross compilation for MOXA arm9, problems ... In-Reply-To: <20110510132248.GA3221@corelatus.se> References: <1305030162.4012.18.camel@adic> <20110510132248.GA3221@corelatus.se> Message-ID: <1305208560.3904.25.camel@adic> Thanks. I got it finally running after at least disabling the threading as done by the erlang-embedded group. Maybe an overkill with the disables, but so far looks promising. At least "hello world" works ... Attached my xconf, if anyone is interested. Next step is embedding yaws ... Jouni On Tue, 2011-05-10 at 16:22 +0300, Matthias Lang wrote: > Hi, > > > root@REDACTED:/mnt/sd/arm-moxa-linux-gnu# cat /proc/cpuinfo > > Processor : ARM922Tid(wb) rev 1 (v4l) > > > root@REDACTED:/mnt/sd/arm-moxa-linux-gnu# ./bin/erl > > Failed to set thread main status: Invalid argument (22) > > Aborted > > > > Does that ring any bells for possible reasons? > > Don't think I've seen that problem before. FWIW, I run Erlang > cross-compiled for > > Processor : ARM926EJ-S rev 5 (v5l) > > I don't know how close an ARM926EJ-S is to an ARM922Tid(wb). I'm using > using the ELDK toolchain from denx.de (gcc 4.2.2). > > Matt -- Jouni Ryn? mailto://Jouni.Ryno@REDACTED/ http://www.geo.fmi.fi/~ryno/ Finnish Meteorological Institute http://www.fmi.fi/ Observation services http://www.geo.fmi.fi/ P.O.BOX 503 Tel (+358)-9-19294656 FI-00101 Helsinki FAX (+358)-9-19294603 Finland priv-GSM (+358)-50-5302903 "It's just zeros and ones, it cannot be hard" -------------- next part -------------- A non-text attachment was scrubbed... Name: erl-xcomp-arm-moxa-linux-gnu.conf Type: text/x-matlab Size: 10779 bytes Desc: not available URL: From rapsey@REDACTED Thu May 12 15:57:31 2011 From: rapsey@REDACTED (Rapsey) Date: Thu, 12 May 2011 15:57:31 +0200 Subject: [erlang-questions] Start erl in daemon mode at boot In-Reply-To: <6CDEAF54-EE0A-436B-B989-12AF4AA76F5C@gmail.com> References: <6CDEAF54-EE0A-436B-B989-12AF4AA76F5C@gmail.com> Message-ID: Unfortunately it did not help. Sergej On Thu, May 12, 2011 at 3:06 PM, Antoine Koener wrote: > > On May 12, 2011, at 08:54 , Rapsey wrote: > > My current way to run erlang as daemon in ubuntu: > > Script that executes erlang itself with my app: > #!/bin/sh > cd /path/to/ebin > erl +Bd +P 1000000 -env ERL_MAX_PORTS 100000 +K true +A 32 -mnesia dir > '"/path/to/mnesia"' -eval "myapp:start()" > > > Upstart file. Placed in /etc/init/nameofapp.conf. It runs erlang through > dtach, which allows me to enter the console at any time and pipes outout to > a logfile. To attach to erlang simply run: dtach -a /tmp/erl > There is one problem with this setup. sudo stop name_of_app does not work. > > > What about: > > #!/bin/sh > cd /path/to/ebin > erl +Bd +P 1000000 -env ERL_MAX_PORTS 100000 +K true +A 32 -mnesia dir > '"/path/to/mnesia"' -eval "myapp:start()" > > > exec erl +Bd +P 1000000 -env ERL_MAX_PORTS 100000 +K true +A 32 -mnesia dir > '"/path/to/mnesia"' -eval "myapp:start()" > > The stop signal will then be received by erl and not /bin/sh > > It will remove the job, but erlang won't actually be killed. If I want to > turn the daemon off, I have to go to erl console through dtach and execute > q(). > > start on filesystem and net-device-up > stop on runlevel [06] > > env HOME=/home/ubuntu > respawn > console output > > script > exec start-stop-daemon --name NAME_OF_INSTANCE --start --chuid > USER_TO_RUN_AS --exec /usr/bin/dtach -- -c /tmp/erl /PATH/TO/SCRIPT > > /var/log/erl.log > end script > > > Sergej > > On Wed, May 11, 2011 at 10:26 PM, Wes James wrote: > >> Does this help any: >> >> http://ubuntuforums.org/showthread.php?t=648425 >> >> -wes >> >> On Wed, May 11, 2011 at 2:22 PM, Hank Knight >> wrote: >> > I am trying to start erl in daemon mode, using the -detached parameter. >> > >> > It runs correctly when initiated from a command line however it fails >> > when initiated using rc.local at boot time. >> > >> > I am running Erlang on Ubuntu. >> > >> > Any ideas on how to get it to run in daemon mode at boot time? >> > >> > Thanks, >> > Hank >> > _______________________________________________ >> > erlang-questions mailing list >> > erlang-questions@REDACTED >> > http://erlang.org/mailman/listinfo/erlang-questions >> > >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cyplo@REDACTED Thu May 12 16:41:36 2011 From: cyplo@REDACTED (=?UTF-8?Q?Cyryl_P=C5=82otnicki=2DChudyk?=) Date: Thu, 12 May 2011 16:41:36 +0200 Subject: [erlang-questions] debugger - usage & development Message-ID: Hello there ! I wanted to know more about your debugging techniques - do you use console printing a lot, or maybe stick to the debugger ? Also - is there a person or a group of people actively managing Erlang graphical debugger ? If so - what is the proper way of posting my improvement suggestions ? If not - what does it take to become such a person ? -- cyryl From dgud@REDACTED Thu May 12 16:56:27 2011 From: dgud@REDACTED (Dan Gudmundsson) Date: Thu, 12 May 2011 16:56:27 +0200 Subject: [erlang-questions] debugger - usage & development In-Reply-To: References: Message-ID: 2011/5/12 Cyryl P?otnicki-Chudyk : > Hello there ! > > I wanted to know more about your debugging techniques - do you use > console printing a lot, or maybe stick to the debugger ? > I guess everything is used, printing, the debugger and tracing, different problems have different needs. I like to use the debugger on distributed and parallel applications, when I need to control the timing and the order of messages sent and receive involving several nodes and/or processes. > Also - is there a person or a group of people actively managing Erlang > graphical debugger ? Depends on what you mean with actively :-) > If so - what is the proper way of posting my improvement suggestions ? > If not - what does it take to become such a person ? See https://github.com/erlang/otp/wiki/Submitting-patches /Dan > -- > cyryl > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From dang@REDACTED Thu May 12 17:17:47 2011 From: dang@REDACTED (Daniel Goertzen) Date: Thu, 12 May 2011 10:17:47 -0500 Subject: [erlang-questions] debugger - usage & development In-Reply-To: References: Message-ID: I stick with console printing and tracing so I don't have to mess with compiler flags. For tracing recipes, I keep coming back to this page: http://stackoverflow.com/questions/1954894/using-trace-and-dbg-in-erlang Dan. 2011/5/12 Cyryl P?otnicki-Chudyk > Hello there ! > > I wanted to know more about your debugging techniques - do you use > console printing a lot, or maybe stick to the debugger ? > > Also - is there a person or a group of people actively managing Erlang > graphical debugger ? > If so - what is the proper way of posting my improvement suggestions ? > If not - what does it take to become such a person ? > > -- > cyryl > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrtndimitrov@REDACTED Thu May 12 17:28:56 2011 From: mrtndimitrov@REDACTED (Martin Dimitrov) Date: Thu, 12 May 2011 18:28:56 +0300 Subject: [erlang-questions] dialyzer error Message-ID: <4DCBFCB8.7050107@gmail.com> Hi, Please help on this one: I am trying to run dialyzer but receive the following error: dialyzer: {dialyzer_error,"The HOME environment variable needs to be set so that Dialyzer knows where to find the default PLT"} [{dialyzer_plt,error,1}, {dialyzer_options,build,1}, {dialyzer_cl_parse,cl,1}, {dialyzer_cl_parse,start,0}, {dialyzer,plain_cl,0}, {init,start_it,1}, {init,start_em,1}] Thank you, Martin From moxford@REDACTED Thu May 12 20:39:23 2011 From: moxford@REDACTED (Mike Oxford) Date: Thu, 12 May 2011 11:39:23 -0700 Subject: [erlang-questions] Erlang emacs workflow question Message-ID: Write some code C-c C-k to make sure it compiles Spin a release (using rebar) in another window Run the code in another window Is there a better/more streamlined way to do this, all from within emacs (I have erl running in another window.) Optimally it would be C-c C-k to compile it, maybe load the .beam, and test directly from within emacs. I feel like I'm missing something here... Thanks! -mox -------------- next part -------------- An HTML attachment was scrubbed... URL: From moxford@REDACTED Thu May 12 20:44:37 2011 From: moxford@REDACTED (Mike Oxford) Date: Thu, 12 May 2011 11:44:37 -0700 Subject: [erlang-questions] Style question Message-ID: An easy one.... This method works but is there a better way to do this? https://gist.github.com/967699 Thanks! -mox -------------- next part -------------- An HTML attachment was scrubbed... URL: From jack@REDACTED Thu May 12 20:48:22 2011 From: jack@REDACTED (Jack Moffitt) Date: Thu, 12 May 2011 12:48:22 -0600 Subject: [erlang-questions] Style question In-Reply-To: References: Message-ID: > This method works but is there a better way to do this? I think you should assume that mnesia is up and running, and just declare that as a dependency of your application. Then you only have to try and read the data you want, and deal with the failure that the data is not there or the table doesn't exist. Then all the code is gone, and there is just a tiny bit more code in your startup script to launch mnesia. The application:start() call will fail if the mnesia dependency is not satisfied, and your code will fail if the config data is not there. jack. From kamils80@REDACTED Thu May 12 20:54:24 2011 From: kamils80@REDACTED (Kamil Shakirov) Date: Fri, 13 May 2011 01:54:24 +0700 Subject: [erlang-questions] Erlang emacs workflow question In-Reply-To: References: Message-ID: <6542FA0B-428A-4900-8611-1BC3AD358DBE@gmail.com> Hi Mike, Have you tried Distel (http://github.com/massemanet/distel) that extends standard erlang-mode turning it into a nice Erlang IDE? It does the same job as SLIME for Common Lisp. On May 13, 2011, at 1:39 AM, Mike Oxford wrote: > Write some code > C-c C-k to make sure it compiles > Spin a release (using rebar) in another window > Run the code in another window > > Is there a better/more streamlined way to do this, all from within emacs (I have erl running in another window.) > Optimally it would be C-c C-k to compile it, maybe load the .beam, and test directly from within emacs. > > I feel like I'm missing something here... > > Thanks! > > -mox > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions --ska From comptekki@REDACTED Thu May 12 20:12:37 2011 From: comptekki@REDACTED (Wes James) Date: Thu, 12 May 2011 12:12:37 -0600 Subject: [erlang-questions] Removing Element from XML In-Reply-To: References: Message-ID: On Thu, May 12, 2011 at 7:38 AM, Maruthavanan Subbarayan wrote: > Hi, > I have a xml document like below > > 1 > Erlang >
> Street 1 > Country 1 >
>
> I have done xmerl_scan:stream, now I need to remove the id , name node such > that I have only address. > How do I remove so that I can below. > >
> Street 1 > Country 1 >
>
> Thanks, > Marutha Something like this?? where f.xml is a copy of your sample from your email pasted in to a file: -module(px). -include("/usr/local/lib/erlang/lib/xmerl-1.2.8/include/xmerl.hrl"). -export([t/0]). -define(F, "f.xml"). t() -> {P1,_}=xmerl_scan:file(?F), {_, _, _, _, _, _, _, _, Q9, _, _, _} = P1, [_, _, _, _, _, R6, _]=Q9, R6, S=xmerl:export_simple( [ {xmlText,[{emp,1}],1,[],"\n",text}, {xmlElement,emp,emp,[], {xmlNamespace,[],[]}, [],1,[], [ {xmlText,[{emp,1}],5,[],"\n",text}, R6, {xmlText,[{emp,1}],7,[],"\n",text} ], [],".",undeclared} ], xmerl_xml), % lists:flatten(S) io:format("~s~n", [S]). $ erl Erlang R14B03 (erts-5.8.4) [source] [smp:4:4] [rq:4] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.8.4 (abort with ^G) 1> c(px). {ok,px} 2> px:t().
Street 1 Country 1
ok 3> lines such as: {xmlText,[{emp,1}],1,[],"\n",text}, were put in for line feeds for viewing purposes, they are not necessary for real processing. references: http://www.erlang.org/doc/apps/xmerl/xmerl_ug.html http://www.erlang.org/doc/man/xmerl.html http://stackoverflow.com/questions/1227241/building-an-xmerl-document-in-erlang -wes From moxford@REDACTED Thu May 12 21:21:16 2011 From: moxford@REDACTED (Mike Oxford) Date: Thu, 12 May 2011 12:21:16 -0700 Subject: [erlang-questions] Erlang emacs workflow question In-Reply-To: <6542FA0B-428A-4900-8611-1BC3AD358DBE@gmail.com> References: <6542FA0B-428A-4900-8611-1BC3AD358DBE@gmail.com> Message-ID: I have it installed but it seems to not work well for me. (User error is most likely the cuplrit.) I get "EXIT: <0.6.0> [emacs-error "(cl-assertion-failed (derl-node-p node))"]" with just about every command I try. I wasn't sure if distel was worth spending time digging into if there were better options around, or better workflows. If "distel is it" then I'll spend the time to dig into figuring out why it doesn't work for me. :) -mox On Thu, May 12, 2011 at 11:54 AM, Kamil Shakirov wrote: > Hi Mike, > > Have you tried Distel (http://github.com/massemanet/distel) that extends > standard erlang-mode turning it into a nice Erlang IDE? It does the same job > as SLIME for Common Lisp. > > On May 13, 2011, at 1:39 AM, Mike Oxford wrote: > > > Write some code > > C-c C-k to make sure it compiles > > Spin a release (using rebar) in another window > > Run the code in another window > > > > Is there a better/more streamlined way to do this, all from within emacs > (I have erl running in another window.) > > Optimally it would be C-c C-k to compile it, maybe load the .beam, and > test directly from within emacs. > > > > I feel like I'm missing something here... > > > > Thanks! > > > > -mox > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > --ska > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kamils80@REDACTED Thu May 12 21:37:41 2011 From: kamils80@REDACTED (Kamil Shakirov) Date: Fri, 13 May 2011 02:37:41 +0700 Subject: [erlang-questions] Erlang emacs workflow question In-Reply-To: References: <6542FA0B-428A-4900-8611-1BC3AD358DBE@gmail.com> Message-ID: <60A6023E-5685-4AAD-AB4B-94E61965A01E@gmail.com> Hmm, works for me: GNU Emacs 23 (OSX and GNU/Linux), R14B, distel HEAD from git. On May 13, 2011, at 2:21 AM, Mike Oxford wrote: > I have it installed but it seems to not work well for me. (User error is most likely the cuplrit.) > > I get "EXIT: <0.6.0> [emacs-error "(cl-assertion-failed (derl-node-p node))"]" with just about every command I try. > I wasn't sure if distel was worth spending time digging into if there were better options around, or better workflows. > > If "distel is it" then I'll spend the time to dig into figuring out why it doesn't work for me. :) > > -mox > > On Thu, May 12, 2011 at 11:54 AM, Kamil Shakirov wrote: > Hi Mike, > > Have you tried Distel (http://github.com/massemanet/distel) that extends standard erlang-mode turning it into a nice Erlang IDE? It does the same job as SLIME for Common Lisp. > > On May 13, 2011, at 1:39 AM, Mike Oxford wrote: > > > Write some code > > C-c C-k to make sure it compiles > > Spin a release (using rebar) in another window > > Run the code in another window > > > > Is there a better/more streamlined way to do this, all from within emacs (I have erl running in another window.) > > Optimally it would be C-c C-k to compile it, maybe load the .beam, and test directly from within emacs. > > > > I feel like I'm missing something here... > > > > Thanks! > > > > -mox > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > --ska > > --ska -------------- next part -------------- An HTML attachment was scrubbed... URL: From watson.timothy@REDACTED Thu May 12 22:07:52 2011 From: watson.timothy@REDACTED (Tim Watson) Date: Thu, 12 May 2011 21:07:52 +0100 Subject: [erlang-questions] Style question In-Reply-To: References: Message-ID: > I think you should assume that mnesia is up and running, and just > declare that as a dependency of your application. Then you only have > to try and read the data you want, and deal with the failure that the > data is not there or the table doesn't exist. Better still, use http://github.com/esl/setup to generate a "run once" setup script that will create your schema/tables and then, as Jack suggests, just assume mnesia is up and running. Or you could use https://github.com/hyperthunk/appstart to ensure that mnesia is running before starting your app: start() -> appstart:start_deps(myapp), myapp_sup:start_link(). From watson.timothy@REDACTED Thu May 12 22:11:58 2011 From: watson.timothy@REDACTED (Tim Watson) Date: Thu, 12 May 2011 21:11:58 +0100 Subject: [erlang-questions] Style question In-Reply-To: References: Message-ID: > Better still, use http://github.com/esl/setup to generate a "run once" > setup script that will create your schema/tables and then, An example of your subsequent setup script can be seen here: https://github.com/hyperthunk/nodewatch/blob/master/release/files/setup.sh - obviously there's a bit of build/release hackery required to get this working. Take a look at the rebar.config and build subdirectory for more insight. From watson.timothy@REDACTED Thu May 12 22:20:42 2011 From: watson.timothy@REDACTED (Tim Watson) Date: Thu, 12 May 2011 21:20:42 +0100 Subject: [erlang-questions] Determine if a binary is ref-counted in port driver code Message-ID: In a port driver I'm working on, I pass an iolist to driver_outputv and on encountering a binary, need to know whether it is a ref-counted binary or not (i.e. a so-called heap binary). The location of the action data in the ErlIOVec depends on this apparently. I've seen some anecdotal evidence (on the mailing list) to suggest that if the binary is > 64 bytes it will be ref-counted, but I want to know if there is an API (or perhaps a macro in the OTP source tree) that I can use to determine this? Currently I'm using a hack-around like so: if (hsize->xsl_size < 64) { data = &ev->iov[++bin_idx].iov_base[0]; } else { data = ev->binv[++bin_idx]->orig_bytes; } This code (taken from https://github.com/hyperthunk/erlxsl/blob/master/c_src/erlxsl.c) seems to work, but I'm fairly sure it's not The Right Thing To Do (TM). Any pointers to better solutions would be much appreciated. Cheers, Tim From moxford@REDACTED Thu May 12 22:43:47 2011 From: moxford@REDACTED (Mike Oxford) Date: Thu, 12 May 2011 13:43:47 -0700 Subject: [erlang-questions] Style question In-Reply-To: References: Message-ID: Thanks for the links, I'll scope them out! One quick question: How is 'appstart' better than just putting the dependency in the reltool? Thanks again! -mox On Thu, May 12, 2011 at 1:11 PM, Tim Watson wrote: > > Better still, use http://github.com/esl/setup to generate a "run once" > > setup script that will create your schema/tables and then, > > An example of your subsequent setup script can be seen here: > https://github.com/hyperthunk/nodewatch/blob/master/release/files/setup.sh > - obviously there's a bit of build/release hackery required to get > this working. Take a look at the rebar.config and build subdirectory > for more insight. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From watson.timothy@REDACTED Thu May 12 23:48:47 2011 From: watson.timothy@REDACTED (Tim Watson) Date: Thu, 12 May 2011 22:48:47 +0100 Subject: [erlang-questions] Style question In-Reply-To: References: Message-ID: > One quick question: ?How is 'appstart' better than just putting the > dependency in the reltool? It's not - it's intended for cold start outside of a release (e.g. in a dev environment). Packaging a release and using esl/setup is the right way to do things. Having to build a release just to poke around in your code or run tests is a bit cumbersome though, which is where appstart can prove handy. From sam@REDACTED Fri May 13 04:16:09 2011 From: sam@REDACTED (Sam Bobroff) Date: Fri, 13 May 2011 12:16:09 +1000 Subject: [erlang-questions] funs versus code loading Message-ID: Hi all, I've encountered a situation that makes my brain hurt and I was wondering if anyone could help me understand it. It's so strange that it may be a bug, if so please let me know and I'll do whatever groundwork is necessary to get it tracked down. Anyway on to the situation: It appears that when: * Executing a Fun, * that contains a local function call, * in a process running in the old code of a module that has both current and old versions loaded, * the local function call will sometimes go to the current code and sometimes go to the old code. It appears that the decision is based somehow on the content of the code in the current version. Obviously an example is in order: --- begin foo.erl --- -module(foo). -ifdef(BODY). -export([start/0, loop/0]). start() -> register(?MODULE, spawn(?MODULE, loop, [])). loop() -> io:fwrite("loop version ~p\n", [?V]), receive _ -> F = fun () -> loop() end, F() end. -endif. --- end foo.erl --- Armed with this file, we can do this: $ erl Erlang R14B02 (erts-5.8.3) [source] [smp:4:4] [rq:4] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.8.3 (abort with ^G) 1> compile:file("foo", [{d,'BODY'}, {d,'V',1}]). {ok,foo,[]} 2> foo:start(). loop version 1 true 3> compile:file("foo", [{d,'BODY'}, {d,'V',2}]). {ok,foo,[]} 4> code:load_file(foo). {module,foo} 5> foo ! x. loop version 2 x The local function call in the Fun has called from the old version into the current version of the module (not what I expected). Run the same sequence again but this time load a module that is empty: $ erl Erlang R14B02 (erts-5.8.3) [source] [smp:4:4] [rq:4] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.8.3 (abort with ^G) 1> compile:file("foo", [{d,'BODY'}, {d,'V',1}]). {ok,foo,[]} 2> foo:start(). loop version 1 true 3> compile:file("foo", [{d,'V',2}]). {ok,foo,[]} 4> code:load_file(foo). {module,foo} 5> foo ! x. loop version 1 x The local function call in the Fun has stayed in the old version of the module (actually what I expected). Some changes other than emptying the body of the module seem to have a similar effect but I haven't tracked down exactly what the trigger is. My system is Ubuntu 11.04 running Erlang R14B02 and I haven't yet checked older versions of Erlang for the same behaviour. Thanks, Sam. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffm@REDACTED Fri May 13 05:13:24 2011 From: jeffm@REDACTED (jm) Date: Fri, 13 May 2011 13:13:24 +1000 Subject: [erlang-questions] sunrpc module? Message-ID: <4DCCA1D4.6030300@ghostgun.com> Is there a module to make sun style rpc calls from erlang, eg to portmapper? Jeff. From vances@REDACTED Fri May 13 06:24:12 2011 From: vances@REDACTED (Vance Shipley) Date: Fri, 13 May 2011 09:54:12 +0530 Subject: [erlang-questions] Porting appmon/pman/debugger/tv to Wx? Message-ID: <20110513042410.GE43920@aluminum-2.local> In the User's Guide for the GS application it says: "GS is not maintained and we plan to deprecate and remove it from the distribution as soon as possible, maybe already in the next major release (R15)." I am hopeful that gs wouldn't be removed until the tools were ported over to use wx. Is that a fair assumption? -- -Vance From bengt.kleberg@REDACTED Fri May 13 06:20:38 2011 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Fri, 13 May 2011 06:20:38 +0200 Subject: [erlang-questions] dialyzer error In-Reply-To: <4DCBFCB8.7050107@gmail.com> References: <4DCBFCB8.7050107@gmail.com> Message-ID: <1305260438.5044.1.camel@seasc1137> Greetings, $HOME is used by dialyzer to find the default plt. $HOME is supposed to be present (POSIX). What do you get if you do echo $HOME before starting dialyzer? bengt On Thu, 2011-05-12 at 17:28 +0200, Martin Dimitrov wrote: > Hi, > > Please help on this one: > > I am trying to run dialyzer but receive the following error: > dialyzer: {dialyzer_error,"The HOME environment variable needs to be set > so that Dialyzer knows where to find the default PLT"} > [{dialyzer_plt,error,1}, > {dialyzer_options,build,1}, > {dialyzer_cl_parse,cl,1}, > {dialyzer_cl_parse,start,0}, > {dialyzer,plain_cl,0}, > {init,start_it,1}, > {init,start_em,1}] > > Thank you, > > Martin > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From dan@REDACTED Fri May 13 06:44:51 2011 From: dan@REDACTED (Daniel Dormont) Date: Fri, 13 May 2011 00:44:51 -0400 Subject: [erlang-questions] funs versus code loading In-Reply-To: References: Message-ID: I'm far from an expert, but I repeated your test just for fun on R12B and got the same result. I did a few other tests as well. Perhaps unsurprisingly, changing "loop()" to "foo:loop()" produced the same result in test 1 and an error {undef,[{foo,loop,[]}]} in test 2. That is, the old code seems to be fully discarded in that case. Maybe more surprisingly, loading the code for a third time in test 1 results in an error "=ERROR REPORT==== 13-May-2011::00:13:18 === Loading of /Users/dan/foo.beam failed: not_purged {error,not_purged}" However, using the shell command l/1 instead of code:load_file/1 avoids this error. I'll leave it to the experts to tell us why :) dan On Thu, May 12, 2011 at 10:16 PM, Sam Bobroff wrote: > Hi all, > > I've encountered a situation that makes my brain hurt and I was wondering > if anyone could help me understand it. It's so strange that it may be a bug, > if so please let me know and I'll do whatever groundwork is necessary to get > it tracked down. Anyway on to the situation: > > It appears that when: > * Executing a Fun, > * that contains a local function call, > * in a process running in the old code of a module that has both current > and old versions loaded, > * the local function call will sometimes go to the current code and > sometimes go to the old code. > > It appears that the decision is based somehow on the content of the code in > the current version. > > Obviously an example is in order: > > --- begin foo.erl --- > -module(foo). > -ifdef(BODY). > -export([start/0, loop/0]). > start() -> > register(?MODULE, spawn(?MODULE, loop, [])). > loop() -> > io:fwrite("loop version ~p\n", [?V]), > receive > _ -> > F = fun () -> loop() end, > F() > end. > -endif. > --- end foo.erl --- > > Armed with this file, we can do this: > > $ erl > Erlang R14B02 (erts-5.8.3) [source] [smp:4:4] [rq:4] [async-threads:0] > [hipe] [kernel-poll:false] > > Eshell V5.8.3 (abort with ^G) > 1> compile:file("foo", [{d,'BODY'}, {d,'V',1}]). > {ok,foo,[]} > 2> foo:start(). > loop version 1 > true > 3> compile:file("foo", [{d,'BODY'}, {d,'V',2}]). > {ok,foo,[]} > 4> code:load_file(foo). > {module,foo} > 5> foo ! x. > loop version 2 > x > > The local function call in the Fun has called from the old version into the > current version of the module (not what I expected). > Run the same sequence again but this time load a module that is empty: > > $ erl > Erlang R14B02 (erts-5.8.3) [source] [smp:4:4] [rq:4] [async-threads:0] > [hipe] [kernel-poll:false] > > Eshell V5.8.3 (abort with ^G) > 1> compile:file("foo", [{d,'BODY'}, {d,'V',1}]). > {ok,foo,[]} > 2> foo:start(). > loop version 1 > true > 3> compile:file("foo", [{d,'V',2}]). > {ok,foo,[]} > 4> code:load_file(foo). > {module,foo} > 5> foo ! x. > loop version 1 > x > > The local function call in the Fun has stayed in the old version of the > module (actually what I expected). > > Some changes other than emptying the body of the module seem to have a > similar effect but I haven't tracked down exactly what the trigger is. > > My system is Ubuntu 11.04 running Erlang R14B02 and I haven't yet checked > older versions of Erlang for the same behaviour. > > Thanks, > Sam. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrtndimitrov@REDACTED Fri May 13 06:45:59 2011 From: mrtndimitrov@REDACTED (Martin Dimitrov) Date: Fri, 13 May 2011 07:45:59 +0300 Subject: [erlang-questions] dialyzer error In-Reply-To: <1305260438.5044.1.camel@seasc1137> References: <4DCBFCB8.7050107@gmail.com> <1305260438.5044.1.camel@seasc1137> Message-ID: <4DCCB787.8030100@gmail.com> I forgot to mention that I am on Windows. There is no HOME variable. Thanks, Martin On 5/13/2011 7:20 AM, Bengt Kleberg wrote: > Greetings, > > $HOME is used by dialyzer to find the default plt. $HOME is supposed to > be present (POSIX). What do you get if you do > echo $HOME > before starting dialyzer? > > > bengt > > On Thu, 2011-05-12 at 17:28 +0200, Martin Dimitrov wrote: >> Hi, >> >> Please help on this one: >> >> I am trying to run dialyzer but receive the following error: >> dialyzer: {dialyzer_error,"The HOME environment variable needs to be set >> so that Dialyzer knows where to find the default PLT"} >> [{dialyzer_plt,error,1}, >> {dialyzer_options,build,1}, >> {dialyzer_cl_parse,cl,1}, >> {dialyzer_cl_parse,start,0}, >> {dialyzer,plain_cl,0}, >> {init,start_it,1}, >> {init,start_em,1}] >> >> Thank you, >> >> Martin >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From corticalcomputer@REDACTED Fri May 13 06:47:50 2011 From: corticalcomputer@REDACTED (G.S.) Date: Thu, 12 May 2011 21:47:50 -0700 Subject: [erlang-questions] Porting appmon/pman/debugger/tv to Wx? In-Reply-To: <20110513042410.GE43920@aluminum-2.local> References: <20110513042410.GE43920@aluminum-2.local> Message-ID: I'm hoping that GS will not be removed at all. I still don't see any benefit at all to move to wx. On Thu, May 12, 2011 at 9:24 PM, Vance Shipley wrote: > In the User's Guide for the GS application it says: > > "GS is not maintained and we plan to deprecate and remove it from > the distribution as soon as possible, maybe already in the next > major release (R15)." > > I am hopeful that gs wouldn't be removed until the tools were ported > over to use wx. Is that a fair assumption? > > -- > -Vance > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From enewhuis@REDACTED Fri May 13 06:48:53 2011 From: enewhuis@REDACTED (Eric Newhuis (personal)) Date: Thu, 12 May 2011 23:48:53 -0500 Subject: [erlang-questions] What's the most efficient method to broadcast a message to multiple (100Ks) of processes? In-Reply-To: <1a8c7fff-d999-49ba-b34b-cfa9c1868db9@c10g2000yqh.googlegroups.com> References: <1a8c7fff-d999-49ba-b34b-cfa9c1868db9@c10g2000yqh.googlegroups.com> Message-ID: Um, are your processes in the same Erlang node (OS process) or are they distributed? Are they distributed on the same network segment or over the internet? What kinf of ping times do you get from the worst-case host? If distributed then the only correct answer is to use hardware multicast and write your own binary packet readers. ;-) Or maybe there is already some library for that. Hm. I recall gen_tcp or something perhaps setup as an IP multicast reader/writer. Memory doesn't serve me well from a life I led over 15 years ago. Seriously if you really do have 100,000 clients then you may need to say something about message size, frequency, bursting, etc., before this could be better answered. Also I worry about Erlang's networking kernel sending heartbeats over the net. Is this all local or are we talking internets? On Oct 7, 2010, at 7:01 AM, Zvi wrote: > Hi, > > what's the most efficient method to broadcast a message to multiple > (100Ks) of processes? > > The most naive way is: > > [ Pid ! Msg || Pid<-Pids ]. > > less naive method: > > [ spawn(fun() -> [Pid ! Msg || Pid<-PidsSublist] end) || > PidsSublist <- partition(Pids, N) ]. > > where partition(L,N) splits list L into N sublists. > > Any ideas for better method? > > thanks, > Zvi > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > From sam@REDACTED Fri May 13 06:52:19 2011 From: sam@REDACTED (Sam Bobroff) Date: Fri, 13 May 2011 14:52:19 +1000 Subject: [erlang-questions] funs versus code loading In-Reply-To: References: Message-ID: Thanks for taking a look at this :-) On 13 May 2011 14:44, Daniel Dormont wrote: > I'm far from an expert, but I repeated your test just for fun on R12B and > got the same result. I did a few other tests as well. > > Perhaps unsurprisingly, changing "loop()" to "foo:loop()" produced the same > result in test 1 and an error {undef,[{foo,loop,[]}]} in test 2. That is, > the old code seems to be fully discarded in that case. > Yes, unsurprising because doing an explicit "external" call is supposed to transition into the newest code version. Maybe more surprisingly, loading the code for a third time in test 1 results > in an error "=ERROR REPORT==== 13-May-2011::00:13:18 === > Loading of /Users/dan/foo.beam failed: not_purged > {error,not_purged}" > This isn't too surprising to me: code:load_file() does not do an implicit code:purge() and that error is normal in that case. Because there is an old version of the module loaded, you need to do code:purge(foo) before you can issue another code:load_file(). However, using the shell command l/1 instead of code:load_file/1 avoids this > error. I'll leave it to the experts to tell us why :) > I can answer that one: l() does an implicit code:purge() (although it doesn't say so in it's little help description). > dan > > On Thu, May 12, 2011 at 10:16 PM, Sam Bobroff wrote: > >> Hi all, >> >> I've encountered a situation that makes my brain hurt and I was wondering >> if anyone could help me understand it. It's so strange that it may be a bug, >> if so please let me know and I'll do whatever groundwork is necessary to get >> it tracked down. Anyway on to the situation: >> >> It appears that when: >> * Executing a Fun, >> * that contains a local function call, >> * in a process running in the old code of a module that has both current >> and old versions loaded, >> * the local function call will sometimes go to the current code and >> sometimes go to the old code. >> >> It appears that the decision is based somehow on the content of the code >> in the current version. >> >> Obviously an example is in order: >> >> --- begin foo.erl --- >> -module(foo). >> -ifdef(BODY). >> -export([start/0, loop/0]). >> start() -> >> register(?MODULE, spawn(?MODULE, loop, [])). >> loop() -> >> io:fwrite("loop version ~p\n", [?V]), >> receive >> _ -> >> F = fun () -> loop() end, >> F() >> end. >> -endif. >> --- end foo.erl --- >> >> Armed with this file, we can do this: >> >> $ erl >> Erlang R14B02 (erts-5.8.3) [source] [smp:4:4] [rq:4] [async-threads:0] >> [hipe] [kernel-poll:false] >> >> Eshell V5.8.3 (abort with ^G) >> 1> compile:file("foo", [{d,'BODY'}, {d,'V',1}]). >> {ok,foo,[]} >> 2> foo:start(). >> loop version 1 >> true >> 3> compile:file("foo", [{d,'BODY'}, {d,'V',2}]). >> {ok,foo,[]} >> 4> code:load_file(foo). >> {module,foo} >> 5> foo ! x. >> loop version 2 >> x >> >> The local function call in the Fun has called from the old version into >> the current version of the module (not what I expected). >> Run the same sequence again but this time load a module that is empty: >> >> $ erl >> Erlang R14B02 (erts-5.8.3) [source] [smp:4:4] [rq:4] [async-threads:0] >> [hipe] [kernel-poll:false] >> >> Eshell V5.8.3 (abort with ^G) >> 1> compile:file("foo", [{d,'BODY'}, {d,'V',1}]). >> {ok,foo,[]} >> 2> foo:start(). >> loop version 1 >> true >> 3> compile:file("foo", [{d,'V',2}]). >> {ok,foo,[]} >> 4> code:load_file(foo). >> {module,foo} >> 5> foo ! x. >> loop version 1 >> x >> >> The local function call in the Fun has stayed in the old version of the >> module (actually what I expected). >> >> Some changes other than emptying the body of the module seem to have a >> similar effect but I haven't tracked down exactly what the trigger is. >> >> My system is Ubuntu 11.04 running Erlang R14B02 and I haven't yet checked >> older versions of Erlang for the same behaviour. >> >> Thanks, >> Sam. >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.kleberg@REDACTED Fri May 13 06:59:54 2011 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Fri, 13 May 2011 06:59:54 +0200 Subject: [erlang-questions] dialyzer error In-Reply-To: <4DCCB787.8030100@gmail.com> References: <4DCBFCB8.7050107@gmail.com> <1305260438.5044.1.camel@seasc1137> <4DCCB787.8030100@gmail.com> Message-ID: <1305262794.5044.7.camel@seasc1137> Is there a way to set environment variables in Windows? If so, try to set such a variable called HOME to a directory you can read/write in. Then start dialyzer. bengt On Fri, 2011-05-13 at 06:45 +0200, Martin Dimitrov wrote: > I forgot to mention that I am on Windows. There is no HOME variable. > > Thanks, > > Martin > > > > > > On 5/13/2011 7:20 AM, Bengt Kleberg wrote: > > Greetings, > > > > $HOME is used by dialyzer to find the default plt. $HOME is supposed to > > be present (POSIX). What do you get if you do > > echo $HOME > > before starting dialyzer? > > > > > > bengt > > > > On Thu, 2011-05-12 at 17:28 +0200, Martin Dimitrov wrote: > >> Hi, > >> > >> Please help on this one: > >> > >> I am trying to run dialyzer but receive the following error: > >> dialyzer: {dialyzer_error,"The HOME environment variable needs to be set > >> so that Dialyzer knows where to find the default PLT"} > >> [{dialyzer_plt,error,1}, > >> {dialyzer_options,build,1}, > >> {dialyzer_cl_parse,cl,1}, > >> {dialyzer_cl_parse,start,0}, > >> {dialyzer,plain_cl,0}, > >> {init,start_it,1}, > >> {init,start_em,1}] > >> > >> Thank you, > >> > >> Martin > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questions@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From vmanis@REDACTED Fri May 13 07:24:43 2011 From: vmanis@REDACTED (Vincent Manis) Date: Thu, 12 May 2011 22:24:43 -0700 Subject: [erlang-questions] dialyzer error In-Reply-To: <1305262794.5044.7.camel@seasc1137> References: <4DCBFCB8.7050107@gmail.com> <1305260438.5044.1.camel@seasc1137> <4DCCB787.8030100@gmail.com> <1305262794.5044.7.camel@seasc1137> Message-ID: <47DD6CF7-55DB-47FE-8F3A-82EDEDE1E71B@telus.net> On 2011-05-12, at 21:59, Bengt Kleberg wrote: > Is there a way to set environment variables in Windows? If so, try to > set such a variable called HOME to a directory you can read/write in. > Then start dialyzer. My Windows days are long since behind me, but I believe what you do is to go to the System applet in the Control Panel, and select the Advanced button. One of the tabs that shows up says Environment. You want to create a new variable in the System (rather that User) set. Yes, I know that sounds pretty random. If you're activating your program from the Command Prompt, you can say SET HOME=c:\myhome before you invoke the program. This is the same as export HOME=/home/myhome in Unix/Linux. Windows has two variables, HOMEDRIVE and HOMEPATH, which combined lead you to what Windows thinks is your home directory, c:\documents and settings\smith, in XP. I always had a different home directory in Windows, because so many programs dislike spaces in file or directory names. Hope that helps -- vincent From ngreco@REDACTED Fri May 13 08:08:50 2011 From: ngreco@REDACTED (Nahuel Greco) Date: Fri, 13 May 2011 03:08:50 -0300 Subject: [erlang-questions] funs versus code loading In-Reply-To: References: Message-ID: Sam, check this thread: http://thread.gmane.org/gmane.comp.lang.erlang.general/47310 Saludos, Nahuel Greco. On Thu, May 12, 2011 at 11:16 PM, Sam Bobroff wrote: > Hi all, > I've encountered a situation that makes my brain hurt and I was wondering if > anyone could help me understand it. It's so strange that it may be a bug, if > so please let me know and I'll do whatever groundwork is necessary to get it > tracked down. Anyway on to the situation: > It appears that when: > * Executing a Fun, > * that contains a local function call, > * in a process running in the old code of a module that has both current and > old versions loaded, > * the local function call will sometimes go to the current code and > sometimes go to the old code. > It appears that the decision is based somehow on the content of the code in > the current version. > Obviously an example is in order: > --- begin foo.erl --- > -module(foo). > -ifdef(BODY). > -export([start/0, loop/0]). > start() -> > ? ? ? ? register(?MODULE, spawn(?MODULE, loop, [])). > loop() -> > ? ? ? ? io:fwrite("loop version ~p\n", [?V]), > ? ? ? ? receive > ? ? ? ? ? ? ? ? _ -> > ? ? ? ? ? ? ? ? ? ? ? ? F = fun () -> loop() end, > ? ? ? ? ? ? ? ? ? ? ? ? F() > ? ? ? ? end. > -endif. > --- end foo.erl --- > Armed with this file, we can do this: > $ erl > Erlang R14B02 (erts-5.8.3) [source] [smp:4:4] [rq:4] [async-threads:0] > [hipe] [kernel-poll:false] > Eshell V5.8.3 ?(abort with ^G) > 1> compile:file("foo", [{d,'BODY'}, {d,'V',1}]). > {ok,foo,[]} > 2> foo:start(). > loop version 1 > true > 3> compile:file("foo", [{d,'BODY'}, {d,'V',2}]). > {ok,foo,[]} > 4> code:load_file(foo). > {module,foo} > 5> foo ! x. > loop version 2 > x > The local function call in the Fun has called from the old version into the > current version of the module (not what I expected). > Run the same sequence again but this time load a module that is empty: > $ erl > Erlang R14B02 (erts-5.8.3) [source] [smp:4:4] [rq:4] [async-threads:0] > [hipe] [kernel-poll:false] > Eshell V5.8.3 ?(abort with ^G) > 1> compile:file("foo", [{d,'BODY'}, {d,'V',1}]). > {ok,foo,[]} > 2> foo:start(). > loop version 1 > true > 3> compile:file("foo", [{d,'V',2}]). > {ok,foo,[]} > 4> code:load_file(foo). > {module,foo} > 5> foo ! x. > loop version 1 > x > The local function call in the Fun has stayed in the old version of the > module (actually what I expected). > Some changes other than emptying the body of the module seem to have a > similar effect but I haven't tracked down exactly what the trigger is. > My system is Ubuntu 11.04 running Erlang R14B02 and I haven't yet checked > older versions of Erlang for the same behaviour. > Thanks, > Sam. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > From kenneth.lundin@REDACTED Fri May 13 08:26:22 2011 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Fri, 13 May 2011 08:26:22 +0200 Subject: [erlang-questions] Porting appmon/pman/debugger/tv to Wx? In-Reply-To: References: <20110513042410.GE43920@aluminum-2.local> Message-ID: GS will not be removed until the remaining tools; pman, appmon, tv and etop are ported to wx. The work with porting the tools is already started. In that work we also plan to merge pman, appmon and etop into one single tool since they all partly do the same thing. The benefits with getting rid of GS are many: - GS gives an ugly non native looking look and feel on all platforms - GS is missing a lot of features that are taken for granted in a GUI library today. - We don't want to maintain 2 different GUI libraries with external dependencies ... / Kenneth, Erlang/OTP, Ericsson On Fri, May 13, 2011 at 6:47 AM, G.S. wrote: > I'm hoping that GS will not be removed at all. I still don't see any benefit > at all to move to wx. > > On Thu, May 12, 2011 at 9:24 PM, Vance Shipley wrote: >> >> In the User's Guide for the GS application it says: >> >> ? "GS is not maintained and we plan to deprecate and remove it from >> ? ?the distribution as soon as possible, maybe already in the next >> ? ?major release (R15)." >> >> I am hopeful that gs wouldn't be removed until the tools were ported >> over to use wx. ?Is that a fair assumption? >> >> -- >> ? ? ? ?-Vance >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > From tobias.schlager@REDACTED Fri May 13 08:29:54 2011 From: tobias.schlager@REDACTED (Tobias Schlager) Date: Fri, 13 May 2011 08:29:54 +0200 Subject: [erlang-questions] Erlang emacs workflow question In-Reply-To: References: Message-ID: <4DCCCFE2.9020800@lindenbaum.eu> Hi Mike, you could try erl-mvn-distel emacs integration for the maven-erlang-plugin. It's an emacs mode that currently features * JIT compiling with error markup and tooltips * easy toggling between source and test source * eunit test integration to run single test functions or test modules and report the results * eunit test tracing for debugging Since its an emacs integration for the maven-erlang-plugin you would need to manage your project with maven. erl-mvn-distel is still under development but it does the job quite well. Links: * maven-erlang-plugin http://erlang-plugin.sourceforge.net/ * erl-mvn-distel http://github.com/sheyll/erl-mvn-distel/ Regards Tobias Am 12.05.2011 20:39, schrieb Mike Oxford: > Write some code > C-c C-k to make sure it compiles > Spin a release (using rebar) in another window > Run the code in another window > > Is there a better/more streamlined way to do this, all from within emacs > (I have erl running in another window.) > Optimally it would be C-c C-k to compile it, maybe load the .beam, and > test directly from within emacs. > > I feel like I'm missing something here... > > Thanks! > > -mox > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Lindenbaum GmbH Dipl.-Inform. Tobias Schlager, Software Engineer Erbprinzenstr. 4-12, 76133 Karlsruhe, Deutschland Tel: +49 721 48 08 48 - 000, Fax: +49 721 48 08 48 - 801, E-Mail: tobias.schlager@REDACTED Firmensitz: Erbprinzenstr. 4-12, Eingang A, 76133 Karlsruhe Registergericht: Amtsgericht Mannheim, HRB 706184 Gesch?ftsf?hrer: Sven Behrens, Dr. Ralf Nikolai Steuernummer: 35007/02060, USt. ID: DE 263797265 http://www.lindenbaum.eu From corticalcomputer@REDACTED Fri May 13 08:47:40 2011 From: corticalcomputer@REDACTED (G.S.) Date: Thu, 12 May 2011 23:47:40 -0700 Subject: [erlang-questions] Porting appmon/pman/debugger/tv to Wx? In-Reply-To: References: <20110513042410.GE43920@aluminum-2.local> Message-ID: Kenneth, You are of course right about wx, and the benefits gained from moving to it. I guess my reluctance stems from having used gs for a number of years, and getting so used to it, and because I'm only using a small subset of its features for my projects, so I never had the chance to come across the library's limitations. But when working on a full GUI, I can see where GS might be lacking significantly. So the move to wx would be a generally positive thing. When do you expect porting of the tools will be complete, in less or more than a year? Regards, -Gene On Thu, May 12, 2011 at 11:26 PM, Kenneth Lundin wrote: > GS will not be removed until the remaining tools; pman, appmon, tv and > etop are ported to > wx. > The work with porting the tools is already started. > In that work we also plan to merge pman, appmon and etop into one > single tool since they all partly do the same thing. > > The benefits with getting rid of GS are many: > - GS gives an ugly non native looking look and feel on all platforms > - GS is missing a lot of features that are taken for granted in a GUI > library today. > - We don't want to maintain 2 different GUI libraries with external > dependencies > ... > > / Kenneth, Erlang/OTP, Ericsson > > On Fri, May 13, 2011 at 6:47 AM, G.S. wrote: > > I'm hoping that GS will not be removed at all. I still don't see any > benefit > > at all to move to wx. > > > > On Thu, May 12, 2011 at 9:24 PM, Vance Shipley > wrote: > >> > >> In the User's Guide for the GS application it says: > >> > >> "GS is not maintained and we plan to deprecate and remove it from > >> the distribution as soon as possible, maybe already in the next > >> major release (R15)." > >> > >> I am hopeful that gs wouldn't be removed until the tools were ported > >> over to use wx. Is that a fair assumption? > >> > >> -- > >> -Vance > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questions@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-questions > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From boris.muehmer@REDACTED Fri May 13 09:02:27 2011 From: boris.muehmer@REDACTED (=?UTF-8?Q?Boris_M=C3=BChmer?=) Date: Fri, 13 May 2011 09:02:27 +0200 Subject: [erlang-questions] Porting appmon/pman/debugger/tv to Wx? In-Reply-To: References: <20110513042410.GE43920@aluminum-2.local> Message-ID: It would be great if You would add another layer on top of wx. Basically to abstract the actual "engine" beneath it. Maybe one day wx will be replaced by something like "freeglut", "Ogre3D", or "something completely unknown yet". Or there will be a new environment, where wx can't be build or another (G)UI exists, that should/must be used. - boris From mrtndimitrov@REDACTED Fri May 13 09:02:23 2011 From: mrtndimitrov@REDACTED (Martin Dimitrov) Date: Fri, 13 May 2011 10:02:23 +0300 Subject: [erlang-questions] dialyzer error In-Reply-To: <1305262794.5044.7.camel@seasc1137> References: <4DCBFCB8.7050107@gmail.com> <1305260438.5044.1.camel@seasc1137> <4DCCB787.8030100@gmail.com> <1305262794.5044.7.camel@seasc1137> Message-ID: <4DCCD77F.2040107@gmail.com> Great, thanks! That solved the problem. In case someone else is struggling with this: > SET HOME=C:\ sets the home variable to point to the root of the C drive to print the contents of the variable: > echo %HOME% If the output is %HOME% it means the variable is not set Regards, Martin On 5/13/2011 7:59 AM, Bengt Kleberg wrote: > Is there a way to set environment variables in Windows? If so, try to > set such a variable called HOME to a directory you can read/write in. > Then start dialyzer. > > > bengt > > On Fri, 2011-05-13 at 06:45 +0200, Martin Dimitrov wrote: >> I forgot to mention that I am on Windows. There is no HOME variable. >> >> Thanks, >> >> Martin >> >> >> >> >> >> On 5/13/2011 7:20 AM, Bengt Kleberg wrote: >>> Greetings, >>> >>> $HOME is used by dialyzer to find the default plt. $HOME is supposed to >>> be present (POSIX). What do you get if you do >>> echo $HOME >>> before starting dialyzer? >>> >>> >>> bengt >>> >>> On Thu, 2011-05-12 at 17:28 +0200, Martin Dimitrov wrote: >>>> Hi, >>>> >>>> Please help on this one: >>>> >>>> I am trying to run dialyzer but receive the following error: >>>> dialyzer: {dialyzer_error,"The HOME environment variable needs to be set >>>> so that Dialyzer knows where to find the default PLT"} >>>> [{dialyzer_plt,error,1}, >>>> {dialyzer_options,build,1}, >>>> {dialyzer_cl_parse,cl,1}, >>>> {dialyzer_cl_parse,start,0}, >>>> {dialyzer,plain_cl,0}, >>>> {init,start_it,1}, >>>> {init,start_em,1}] >>>> >>>> Thank you, >>>> >>>> Martin >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From sam@REDACTED Fri May 13 09:05:15 2011 From: sam@REDACTED (Sam Bobroff) Date: Fri, 13 May 2011 17:05:15 +1000 Subject: [erlang-questions] funs versus code loading In-Reply-To: References: Message-ID: On 13 May 2011 16:08, Nahuel Greco wrote: > Sam, check this thread: > > http://thread.gmane.org/gmane.comp.lang.erlang.general/47310 > > Saludos, > Nahuel Greco. > > Ah yes that seems to match exactly what I've observed! Thanks for that :-) I agree with your (and Matthias') comments in that it should be changed in accordance with the patch! In my opinion the current system is confusing and therefore dangerous. Hmm... from poking around in the emulator code it looks like the "hash" is made up of three components XOR'ed together: * the index * the module's name * a "uniq" value Since during code reloading, the module name and index could easily be the same... if the uniq were the same then the emulator would be fooled into thinking it was OK to use the new version of the code... when it was not OK. I couldn't see what system was used to set the uniq value ("old_uniq" in most of the code I saw)... does anyone know what it is? Even without knowing the algorithm, if I can control the Fun's index, and I can see it's uniq, I can probably cause a hash collision by setting the index to a specific value. The reason I ask is that I'm wondering if a hash collision is possible and if that has the potential to crash the emulator. Sam. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustav.simonsson@REDACTED Fri May 13 10:57:03 2011 From: gustav.simonsson@REDACTED (Gustav Simonsson) Date: Fri, 13 May 2011 08:57:03 +0000 (GMT) Subject: [erlang-questions] Determine if a binary is ref-counted in port driver code In-Reply-To: <996513866.175451305276914004.JavaMail.root@zimbra> Message-ID: <1076048168.175471305277023542.JavaMail.root@zimbra> >From http://www.erlang.org/doc/man/erl_driver.html "The ErlDrvBinary structure is a binary, as sent between the emulator and the driver. All binaries are reference counted" Also, this and the following functions might be of use: http://www.erlang.org/doc/man/erl_driver.html#driver_binary_get_refc Best Regards, Gustav Simonsson ----- Original Message ----- From: "Tim Watson" To: erlang-questions@REDACTED Sent: Thursday, May 12, 2011 10:20:42 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: [erlang-questions] Determine if a binary is ref-counted in port driver code In a port driver I'm working on, I pass an iolist to driver_outputv and on encountering a binary, need to know whether it is a ref-counted binary or not (i.e. a so-called heap binary). The location of the action data in the ErlIOVec depends on this apparently. I've seen some anecdotal evidence (on the mailing list) to suggest that if the binary is > 64 bytes it will be ref-counted, but I want to know if there is an API (or perhaps a macro in the OTP source tree) that I can use to determine this? Currently I'm using a hack-around like so: if (hsize->xsl_size < 64) { data = &ev->iov[++bin_idx].iov_base[0]; } else { data = ev->binv[++bin_idx]->orig_bytes; } This code (taken from https://github.com/hyperthunk/erlxsl/blob/master/c_src/erlxsl.c) seems to work, but I'm fairly sure it's not The Right Thing To Do (TM). Any pointers to better solutions would be much appreciated. Cheers, Tim _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions From tony@REDACTED Fri May 13 10:58:27 2011 From: tony@REDACTED (Tony Rogvall) Date: Fri, 13 May 2011 10:58:27 +0200 Subject: [erlang-questions] funs versus code loading In-Reply-To: References: Message-ID: <573D6CAA-997D-4278-84E4-A5362E372EEC@rogvall.se> Hi! On 13 maj 2011, at 09.05, Sam Bobroff wrote: > On 13 May 2011 16:08, Nahuel Greco wrote: > Sam, check this thread: > > http://thread.gmane.org/gmane.comp.lang.erlang.general/47310 > > Saludos, > Nahuel Greco. > > Ah yes that seems to match exactly what I've observed! > > Thanks for that :-) > > I agree with your (and Matthias') comments in that it should be changed in accordance with the patch! > In my opinion the current system is confusing and therefore dangerous. > If you change your example into this: ------------- -module(foo). -ifdef(BODY). -export([start/0, loop/0]). start() -> register(?MODULE, spawn(?MODULE, loop, [])). loop() -> io:fwrite("loop version ~p\n", [?V]), receive _ -> F = fun () -> ?V,loop() end, F() end. -endif. ------------- The only difference is that I put a dummy version value inside the fun. This is enough to make the fun handle unique (in this case). In one project I used a erlang:now value to (mostly) generate a new function reference. > Hmm... from poking around in the emulator code it looks like the "hash" is made up of three components XOR'ed together: > > * the index > * the module's name > * a "uniq" value > > Since during code reloading, the module name and index could easily be the same... if the uniq were the same then the emulator would be fooled into thinking it was OK to use the new version of the code... when it was not OK. > I guess the new_unique (same as module:info) should/could be used some how. > I couldn't see what system was used to set the uniq value ("old_uniq" in most of the code I saw)... does anyone know what it is? > > Even without knowing the algorithm, if I can control the Fun's index, and I can see it's uniq, I can probably cause a hash collision by setting the index to a specific value. > > The reason I ask is that I'm wondering if a hash collision is possible and if that has the potential to crash the emulator. > > Sam. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions "Have run Make so many times I dunno what's installed anymore" -------------- next part -------------- An HTML attachment was scrubbed... URL: From cyplo@REDACTED Fri May 13 11:19:37 2011 From: cyplo@REDACTED (=?UTF-8?Q?Cyryl_P=C5=82otnicki=2DChudyk?=) Date: Fri, 13 May 2011 11:19:37 +0200 Subject: [erlang-questions] compiling R14B02 with WX support on Ubuntu 11.04 Message-ID: Hello there ! I have a problem compiling R14B02 on Ubuntu 11.04. Despite having all wx packages installed the configure program still gives me wx : Can not link the wx driver, wx will NOT be useable anyone already dealt with this ? If not then I'll try to debug this and return to you with the answer. -- cyryl From boris.muehmer@REDACTED Fri May 13 11:40:03 2011 From: boris.muehmer@REDACTED (=?UTF-8?Q?Boris_M=C3=BChmer?=) Date: Fri, 13 May 2011 11:40:03 +0200 Subject: [erlang-questions] compiling R14B02 with WX support on Ubuntu 11.04 In-Reply-To: References: Message-ID: Maybe have a look at: http://boris.muehmer.de/2011/05/07/installing-erlangotp-r14b02-on-ubuntu-11-04-from-source-tarball/ And compare it to what You have done so far. - boris 2011/5/13 Cyryl P?otnicki-Chudyk : > Hello there ! > I have a problem compiling R14B02 on Ubuntu 11.04. > Despite having all wx packages installed the configure program still gives me > > wx ? ? ? ? ? ? : Can not link the wx driver, wx will NOT be useable > > anyone already dealt with this ? > > If not then I'll try to debug this and return to you with the answer. > > > -- > cyryl > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From mapandfold@REDACTED Fri May 13 11:43:25 2011 From: mapandfold@REDACTED (Justus) Date: Fri, 13 May 2011 17:43:25 +0800 Subject: [erlang-questions] Function Declaration Syntax Message-ID: Hi all, I come to a question on function declaration syntax: why does function name appear in each clause? Name(Pattern11,...,Pattern1N) [when GuardSeq1] -> Body1; ...; Name(PatternK1,...,PatternKN) [when GuardSeqK] -> BodyK. It does not provide any information, except that one might make silly mistakes. If omitting it, a new problem is how to indent clauses properly and beautifully. Name(Pattern11,...,Pattern1N) [when GuardSeq1] -> Body1; (PatternK1,...,PatternKN) [when GuardSeqK] -> BodyK. -- Best Regards, Justus From cyplo@REDACTED Fri May 13 11:51:29 2011 From: cyplo@REDACTED (=?UTF-8?Q?Cyryl_P=C5=82otnicki=2DChudyk?=) Date: Fri, 13 May 2011 11:51:29 +0200 Subject: [erlang-questions] compiling R14B02 with WX support on Ubuntu 11.04 In-Reply-To: References: Message-ID: 2011/5/13 Boris M?hmer : > Maybe have a look at: > > ? ?http://boris.muehmer.de/2011/05/07/installing-erlangotp-r14b02-on-ubuntu-11-04-from-source-tarball/ > > And compare it to what You have done so far. > > Thanks for the link ! It seems that I've missed the 'libglu-dev' as the dependency of the wx. Btw my apt-get said that there's no such package, however it selected the similar one which seems to get the job done. i.e. I don't get the configure warning at this time, I'll try compiling some WX examples later on. Here's the apt-get output: 'Note, selecting 'libglu1-mesa-dev' instead of 'libglu-dev' -- cyryl From attila.r.nohl@REDACTED Fri May 13 12:16:36 2011 From: attila.r.nohl@REDACTED (Attila Rajmund Nohl) Date: Fri, 13 May 2011 12:16:36 +0200 Subject: [erlang-questions] Function Declaration Syntax In-Reply-To: References: Message-ID: 2011/5/13, Justus : > Hi all, > > I come to a question on function declaration syntax: why does function > name appear in each clause? > > Name(Pattern11,...,Pattern1N) [when GuardSeq1] -> > Body1; > ...; > Name(PatternK1,...,PatternKN) [when GuardSeqK] -> > BodyK. > > It does not provide any information, except that one might make silly > mistakes. > > If omitting it, a new problem is how to indent clauses properly and > beautifully. And it would also make tools like ctags less useful... From watson.timothy@REDACTED Fri May 13 13:06:45 2011 From: watson.timothy@REDACTED (Tim Watson) Date: Fri, 13 May 2011 12:06:45 +0100 Subject: [erlang-questions] Determine if a binary is ref-counted in port driver code In-Reply-To: <1076048168.175471305277023542.JavaMail.root@zimbra> References: <996513866.175451305276914004.JavaMail.root@zimbra> <1076048168.175471305277023542.JavaMail.root@zimbra> Message-ID: > From http://www.erlang.org/doc/man/erl_driver.html > > "The ErlDrvBinary structure is a binary, as sent between the emulator and the driver. All binaries are reference counted" > > Also, this and the following functions might be of use: > http://www.erlang.org/doc/man/erl_driver.html#driver_binary_get_refc Thanks for the timely response Gustav. That seems to refer to the ErlDrvBinary that is passed between the emulator and the driver. When an iolist of binaries is passed to port_command, for each entry in the ErlIOVec passed to driver_outputv, the data will only be stored in the binv field *if* the binary is not heap allocated. If it is a small/heap-allocated binary, then the data will appear in the iov field instead. In this (latter) case, there is no ErlDrvBinary to examine and the data is present in the iov_base field of the SysIOVec stored in ev->iov[index]. What I'm trying to ascertain is whether or not there is a way to tell whether a given entry in the ErlIOVec structure will reside in the binv or iov field. Have I misunderstood the way this works? The documentation is a little scant, but this thread appears to cover the issue to some extent: http://erlang.org/pipermail/erlang-questions/2006-August/021904.html. From qoocku@REDACTED Fri May 13 14:11:27 2011 From: qoocku@REDACTED (=?UTF-8?B?RGFtaWFuIERvYnJvY3p5xYRza2k=?=) Date: Fri, 13 May 2011 14:11:27 +0200 Subject: [erlang-questions] reltool optimal-minimal config Message-ID: <4DCD1FEF.6010308@gmail.com> Hi List! I'm trying to generate a release (via rebar) and an empty (for me at least) release containing only kernel, stdlib and sasl includes the following (among others) applications: gs edoc wx xmerl Should they really BE or is it some bug in the application dependencies algorithm? By the way: what does "application implicit inclusion" (mentioned in docs) REALLY means? Is it "{applications, [...]}" section in *.app file or a function from a module used in one of another application module function? -- D. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x0CAE3AEB.asc Type: application/pgp-keys Size: 5071 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From gustav.simonsson@REDACTED Fri May 13 14:18:07 2011 From: gustav.simonsson@REDACTED (Gustav Simonsson) Date: Fri, 13 May 2011 12:18:07 +0000 (GMT) Subject: [erlang-questions] Determine if a binary is ref-counted in port driver code In-Reply-To: <431849068.176251305288848319.JavaMail.root@zimbra> Message-ID: <353829845.176321305289087513.JavaMail.root@zimbra> This post talks about how the SysIOVec field in ErlIOVec gets its value depending on the properties of the binaries in the io list: http://www1.erlang.org/pipermail/erlang-questions/2002-October/005859.html and the reply http://www1.erlang.org/pipermail/erlang-questions/2002-October/005860.html It's from 2002 so the behaviour might be different, but the code referenced in the post does checks on the binaries in the io list in order to determine what todo. See erts_write_to_port (line 1085) and io_list_vec_len (line 999) in https://github.com/erlang/otp/blob/dev/erts/emulator/beam/io.c Best Regards, Gustav Simonsson ----- Original Message ----- From: "Tim Watson" To: "Gustav Simonsson" Cc: erlang-questions@REDACTED Sent: Friday, May 13, 2011 1:06:45 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: [erlang-questions] Determine if a binary is ref-counted in port driver code > From http://www.erlang.org/doc/man/erl_driver.html > > "The ErlDrvBinary structure is a binary, as sent between the emulator and the driver. All binaries are reference counted" > > Also, this and the following functions might be of use: > http://www.erlang.org/doc/man/erl_driver.html#driver_binary_get_refc Thanks for the timely response Gustav. That seems to refer to the ErlDrvBinary that is passed between the emulator and the driver. When an iolist of binaries is passed to port_command, for each entry in the ErlIOVec passed to driver_outputv, the data will only be stored in the binv field *if* the binary is not heap allocated. If it is a small/heap-allocated binary, then the data will appear in the iov field instead. In this (latter) case, there is no ErlDrvBinary to examine and the data is present in the iov_base field of the SysIOVec stored in ev->iov[index]. What I'm trying to ascertain is whether or not there is a way to tell whether a given entry in the ErlIOVec structure will reside in the binv or iov field. Have I misunderstood the way this works? The documentation is a little scant, but this thread appears to cover the issue to some extent: http://erlang.org/pipermail/erlang-questions/2006-August/021904.html. From hm@REDACTED Fri May 13 14:34:49 2011 From: hm@REDACTED (=?ISO-8859-1?Q?H=E5kan_Mattsson?=) Date: Fri, 13 May 2011 14:34:49 +0200 Subject: [erlang-questions] reltool optimal-minimal config In-Reply-To: <4DCD1FEF.6010308@gmail.com> References: <4DCD1FEF.6010308@gmail.com> Message-ID: 2011/5/13 Damian Dobroczy?ski : > Hi List! > > I'm trying to generate a release (via rebar) and an empty (for me at > least) release containing only kernel, stdlib and sasl includes the > following (among others) applications: > > gs > edoc > wx > xmerl > > Should they really BE or is it some bug in the application dependencies > algorithm? Yes, I believe that the tool works as expected. Start the reltool GUI and inspect the dependencies. Then you for example will see that hipe uses gs. wx is used by dialyzer, reltool and the debugger. > By the way: what does "application implicit inclusion" > (mentioned in docs) REALLY means? Is it "{applications, [...]}" section > in *.app file or a function from a module used in one of another > application module function? reltool uses BOTH .app files as well as beam files as source when it determines dependencies. /H?kan From robert.virding@REDACTED Fri May 13 14:36:21 2011 From: robert.virding@REDACTED (Robert Virding) Date: Fri, 13 May 2011 12:36:21 +0000 (GMT) Subject: [erlang-questions] Reltool, system crashes and ports In-Reply-To: <1339983442.176451305290146056.JavaMail.root@zimbra> Message-ID: <546897070.176471305290181612.JavaMail.root@zimbra> I was just gently pointing out that wx, and therefore reltool, is not very stable on a common platform. A corollary to this is that it might not be a good thing to base new tools on wx until it is stable, and definitely not convert old, functioning tools to use it. The main point I was (gently) trying to make is that it is a Good Thing when building reliable systems to avoid as much as possible including things in the base system which aren't absolutely necessary and which can be run in other OS processes. It lessens the number of things which can cause the whole system to crash and increases the number of things which you can safely use even if they might crash. In this case it was a graphics interface which caused the crash! So in this context wx as it stands is not safe for use in reliable systems. Robert P.S. The mac wouldn't let me get a core dump, irrespective of my doing "ulimit -c unlimited". Therefore I include at the end some info which it asked me if it could send to apple about the error. It might provide some help. ----- "Dan Gudmundsson" wrote: > Well these kind of mails doesn't help make it more stable either, does > it. > > No patch attached and no debug info. > > And yes wxwidgets is not as stable on mac as the other ports and it's > not 100% system independent, > so erlang code written on linux don't always work on mac if it is not > tested there. > And not everyone one of us have macs to test it with, which makes us > rely on opensource > contributions on platforms not used at Ericsson such as Mac OSX. > And I can't test every gui application written with wx. > > /Dan > > On Thu, May 12, 2011 at 3:05 PM, Robert Virding > wrote: > > I was testing reltool the other day. I opened up the window and was > moving apps around, then I closed the window. And the beam crashed > with "Bus error"! This happened consistently every time I ran reltool. > This started me reflecting on why we originally made it so that ports > ran things in other OS processes, and how good a choice this was for > reliable systems. > > > > Robert > > > > P.S. I am running R14B02 on Mac OSX. > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > --- Process: beam.smp [5121] Path: /usr/local/lib/erlang/erts-5.8.3/bin/beam.smp Identifier: beam.smp Version: ??? (???) Code Type: X86 (Native) Parent Process: bash [3558] Date/Time: 2011-05-12 16:00:12.668 +0200 OS Version: Mac OS X 10.6.7 (10J869) Report Version: 6 Interval Since Last Report: 223222 sec Crashes Since Last Report: 4 Per-App Crashes Since Last Report: 4 Anonymous UUID: 51B429D4-935C-4629-A14C-FA41D4693736 Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x00000000000001bc Crashed Thread: 0 Dispatch queue: com.apple.main-thread Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 libwx_macud-2.8.0.dylib 0x02b9308a wxRadioBox::~wxRadioBox() + 58 1 wxe_driver.so 0x028ba040 EwxRadioBox::~EwxRadioBox() + 80 (wxe_derived_dest.h:456) 2 libwx_macud-2.8.0.dylib 0x02c429f5 wxWindowBase::DestroyChildren() + 85 3 libwx_macud-2.8.0.dylib 0x02bb08da wxWindow::~wxWindow() + 114 4 wxe_driver.so 0x028bb29f EwxPanel::~EwxPanel() + 63 (wxe_derived_dest.h:47) 5 libwx_macud-2.8.0.dylib 0x02c429f5 wxWindowBase::DestroyChildren() + 85 6 libwx_macud-2.8.0.dylib 0x02bb08da wxWindow::~wxWindow() + 114 7 wxe_driver.so 0x028ba1ff EwxNotebook::~EwxNotebook() + 63 (wxe_derived_dest.h:390) 8 libwx_macud-2.8.0.dylib 0x02c429f5 wxWindowBase::DestroyChildren() + 85 9 libwx_macud-2.8.0.dylib 0x02bb08da wxWindow::~wxWindow() + 114 10 wxe_driver.so 0x028bb29f EwxPanel::~EwxPanel() + 63 (wxe_derived_dest.h:47) 11 libwx_macud-2.8.0.dylib 0x02c429f5 wxWindowBase::DestroyChildren() + 85 12 libwx_macud-2.8.0.dylib 0x02bb08da wxWindow::~wxWindow() + 114 13 wxe_driver.so 0x028ba1ff EwxNotebook::~EwxNotebook() + 63 (wxe_derived_dest.h:390) 14 libwx_macud-2.8.0.dylib 0x02c429f5 wxWindowBase::DestroyChildren() + 85 15 libwx_macud-2.8.0.dylib 0x02bb08da wxWindow::~wxWindow() + 114 16 wxe_driver.so 0x028bb29f EwxPanel::~EwxPanel() + 63 (wxe_derived_dest.h:47) 17 libwx_macud-2.8.0.dylib 0x02c429f5 wxWindowBase::DestroyChildren() + 85 18 libwx_macud-2.8.0.dylib 0x02bb08da wxWindow::~wxWindow() + 114 19 wxe_driver.so 0x028bb37f EwxFrame::~EwxFrame() + 63 (wxe_derived_dest.h:29) 20 wxe_driver.so 0x02846f49 WxeApp::wxe_dispatch(wxeCommand&) + 254761 (wxe_funcs.cpp:40) 21 wxe_driver.so 0x02802281 WxeApp::dispatch(wxList*, int, int) + 369 (wxe_impl.cpp:403) 22 wxe_driver.so 0x028022ff WxeApp::dispatch_cmds() + 95 (wxe_impl.cpp:360) 23 libwx_macud-2.8.0.dylib 0x02b31fa7 wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) + 141 24 libwx_macud-2.8.0.dylib 0x02b32edf wxEvtHandler::SearchDynamicEventTable(wxEvent&) + 137 25 libwx_macud-2.8.0.dylib 0x02b349e7 wxEvtHandler::ProcessEvent(wxEvent&) + 169 26 libwx_macud-2.8.0.dylib 0x02bd6421 wxAppBase::ProcessIdle() + 163 27 libwx_macud-2.8.0.dylib 0x02bf72ab wxEventLoopManual::Run() + 171 28 libwx_macud-2.8.0.dylib 0x02bd667b wxAppBase::MainLoop() + 77 29 libwx_macud-2.8.0.dylib 0x02ae4c97 wxEntry(int&, wchar_t**) + 115 30 wxe_driver.so 0x02802027 wxe_main_loop(void*) + 71 (wxe_impl.cpp:229) 31 beam.smp 0x0011d039 erts_sys_main_thread + 265 (sys.c:3043) 32 beam.smp 0x0001fe6f erl_start + 3695 (erl_init.c:1445) Thread 1: 0 libSystem.B.dylib 0x91bfe3fe read$UNIX2003 + 10 1 beam.smp 0x0011e411 signal_dispatcher_thread_func + 49 (sys.c:2907) 2 beam.smp 0x001829b4 thr_wrapper + 132 3 ??? 0xec835356 0 + 3968029526 Thread 2: 0 libSystem.B.dylib 0x91c21046 __semwait_signal + 10 1 libSystem.B.dylib 0x91c20d02 _pthread_cond_wait + 1191 2 libSystem.B.dylib 0x91c22998 pthread_cond_wait$UNIX2003 + 73 3 beam.smp 0x00180aee ethr_cond_wait + 30 Thread 3: 0 libSystem.B.dylib 0x91c21046 __semwait_signal + 10 1 libSystem.B.dylib 0x91c20d02 _pthread_cond_wait + 1191 2 libSystem.B.dylib 0x91c22998 pthread_cond_wait$UNIX2003 + 73 3 beam.smp 0x00180aee ethr_cond_wait + 30 4 ??? 0x008cec81 0 + 9235585 Thread 4: 0 libSystem.B.dylib 0x91c21046 __semwait_signal + 10 1 libSystem.B.dylib 0x91c20d02 _pthread_cond_wait + 1191 2 libSystem.B.dylib 0x91c22998 pthread_cond_wait$UNIX2003 + 73 3 beam.smp 0x00180aee ethr_cond_wait + 30 4 beam.smp 0x001829b4 thr_wrapper + 132 5 ??? 0xec835356 0 + 3968029526 Thread 5: 0 libSystem.B.dylib 0x91c21046 __semwait_signal + 10 1 libSystem.B.dylib 0x91c20d02 _pthread_cond_wait + 1191 2 libSystem.B.dylib 0x91c22998 pthread_cond_wait$UNIX2003 + 73 3 beam.smp 0x00182e9c ethr_event_wait + 124 Thread 6: 0 libSystem.B.dylib 0x91c21046 __semwait_signal + 10 1 libSystem.B.dylib 0x91c20d02 _pthread_cond_wait + 1191 2 libSystem.B.dylib 0x91c22998 pthread_cond_wait$UNIX2003 + 73 3 beam.smp 0x00182e9c ethr_event_wait + 124 Thread 7: 0 libSystem.B.dylib 0x91c12066 select$DARWIN_EXTSN + 10 1 beam.smp 0x00129832 erts_poll_wait_nkp + 354 (erl_poll.c:1959) Thread 8: 0 libSystem.B.dylib 0x91c21046 __semwait_signal + 10 1 libSystem.B.dylib 0x91c20d02 _pthread_cond_wait + 1191 2 libSystem.B.dylib 0x91c22998 pthread_cond_wait$UNIX2003 + 73 3 beam.smp 0x00182e9c ethr_event_wait + 124 Thread 9: Dispatch queue: com.apple.libdispatch-manager 0 libSystem.B.dylib 0x91c19922 kevent + 10 1 libSystem.B.dylib 0x91c1a03c _dispatch_mgr_invoke + 215 2 libSystem.B.dylib 0x91c194f9 _dispatch_queue_invoke + 163 3 libSystem.B.dylib 0x91c1929e _dispatch_worker_thread2 + 240 4 libSystem.B.dylib 0x91c18d21 _pthread_wqthread + 390 5 libSystem.B.dylib 0x91c18b66 start_wqthread + 30 Thread 10: 0 libSystem.B.dylib 0x91c189b2 __workq_kernreturn + 10 1 libSystem.B.dylib 0x91c18f48 _pthread_wqthread + 941 2 libSystem.B.dylib 0x91c18b66 start_wqthread + 30 Thread 11: Thread 0 crashed with X86 Thread State (32-bit): eax: 0x00000000 ebx: 0x02b9305d ecx: 0x000429f0 edx: 0x000fc080 edi: 0x010356f0 esi: 0x010356f0 ebp: 0xbfffb318 esp: 0xbfffb300 ss: 0x0000001f efl: 0x00010206 eip: 0x02b9308a cs: 0x00000017 ds: 0x0000001f es: 0x0000001f fs: 0x00000000 gs: 0x00000037 cr2: 0x000001bc Binary Images: 0x1000 - 0x1a5ff7 +beam.smp ??? (???) /usr/local/lib/erlang/erts-5.8.3/bin/beam.smp 0x29c000 - 0x2a0ff7 libutil.dylib ??? (???) /usr/lib/libutil.dylib 0x2e6000 - 0x2efff7 libwx_macud_gl-2.8.0.dylib 2.8.8 (compatibility 2.6.0) /usr/lib/libwx_macud_gl-2.8.0.dylib 0x138e000 - 0x1392ff7 com.apple.CommonCocoaPanels 4.0 (16) <30D57C5A-2C5E-3A3E-A9D8-F5E968322AD6> /System/Library/CoreServices/CommonCocoaPanels.bundle/Contents/MacOS/CommonCocoaPanels 0x153c000 - 0x153dff7 com.apple.textencoding.unicode 2.3 (2.3) <78A61FD5-70EE-19EA-48D4-3481C640B70D> /System/Library/TextEncodings/Unicode Encodings.bundle/Contents/MacOS/Unicode Encodings 0x2800000 - 0x28effff +wxe_driver.so ??? (???) <6CEA7EA2-A562-8971-D710-0B92D214E6F3> /usr/local/lib/erlang/lib/wx-0.98.9/priv/wxe_driver.so 0x299f000 - 0x2a43ff3 libwx_macud_stc-2.8.0.dylib 2.8.8 (compatibility 2.6.0) /usr/lib/libwx_macud_stc-2.8.0.dylib 0x2a7c000 - 0x3016feb libwx_macud-2.8.0.dylib 2.8.8 (compatibility 2.6.0) /usr/lib/libwx_macud-2.8.0.dylib 0x8fe00000 - 0x8fe4162b dyld 132.1 (???) <749D24EE-54BD-D74B-D305-C13F5E6C95D8> /usr/lib/dyld 0x90003000 - 0x90a56ff7 com.apple.WebCore 6533.21 (6533.21.1) <09CE6602-4DB5-6E93-8593-4E1C57CB202F> /System/Library/Frameworks/WebKit.framework/Versions/A/Frameworks/WebCore.framework/Versions/A/WebCore 0x90a57000 - 0x90a78fe7 com.apple.opencl 12.3.6 (12.3.6) /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL 0x90a79000 - 0x90a7dff7 libGFXShared.dylib ??? (???) <4F2199F0-320F-0B59-0380-D3131D644CBA> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib 0x90b42000 - 0x90b5dff7 libPng.dylib ??? (???) <65E824F7-523A-CC34-ABDD-2A3B12DE1CA9> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib 0x90b5e000 - 0x90ba4ff7 libauto.dylib ??? (???) <29422A70-87CF-10E2-CE59-FEE1234CFAAE> /usr/lib/libauto.dylib 0x90bc4000 - 0x90bc6ff7 libRadiance.dylib ??? (???) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib 0x90bc7000 - 0x90ca1ffb com.apple.DesktopServices 1.5.10 (1.5.10) <2BA08DD4-35A2-A0FF-ADEA-B381F0CEEB81> /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv 0x90cf3000 - 0x90d01ff7 com.apple.opengl 1.6.12 (1.6.12) <81AEF74E-E33A-B021-9CDB-6199104105FF> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL 0x90ffb000 - 0x9131bff3 com.apple.CoreServices.CarbonCore 861.34 (861.34) <3DA9098F-B71B-4BDE-5DE5-4B76C49158EB> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore 0x9131f000 - 0x913c7ffb com.apple.QD 3.36 (???) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD 0x913c8000 - 0x914bcff7 libiconv.2.dylib 7.0.0 (compatibility 7.0.0) <061ABF36-8BA9-79C1-6CE7-EC69A4998F51> /usr/lib/libiconv.2.dylib 0x914bd000 - 0x914c8ff7 libCSync.A.dylib 545.0.0 (compatibility 64.0.0) <4560936D-7730-5DD2-BFD7-95270DDC210A> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCSync.A.dylib 0x914c9000 - 0x917edfef com.apple.HIToolbox 1.6.5 (???) <21164164-41CE-61DE-C567-32E89755CB34> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox 0x91826000 - 0x91830ffb com.apple.speech.recognition.framework 3.11.1 (3.11.1) <7486003F-8FDB-BD6C-CB34-DE45315BD82C> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition 0x91b77000 - 0x91b87ff7 libsasl2.2.dylib 3.15.0 (compatibility 3.0.0) /usr/lib/libsasl2.2.dylib 0x91b88000 - 0x91bc1ff7 libcups.2.dylib 2.8.0 (compatibility 2.0.0) <90C5DE81-1BEF-D807-A898-0FC19BDD14EC> /usr/lib/libcups.2.dylib 0x91bf2000 - 0x91d99ff7 libSystem.B.dylib 125.2.10 (compatibility 1.0.0) /usr/lib/libSystem.B.dylib 0x91d9a000 - 0x91dddff7 libGLU.dylib ??? (???) <2C7B2727-26F6-F29D-9D15-33044E87359F> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib 0x91e3a000 - 0x9271aff7 com.apple.AppKit 6.6.7 (1038.35) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 0x9271b000 - 0x92726ff7 libGL.dylib ??? (???) <4425B9AA-B494-A336-EABB-6BBC9FF4EC4F> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib 0x92c12000 - 0x92caafe7 edu.mit.Kerberos 6.5.11 (6.5.11) /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos 0x92cab000 - 0x92d0fffb com.apple.htmlrendering 72 (1.1.4) <4D451A35-FAB6-1288-71F6-F24A4B6E2371> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HTMLRendering.framework/Versions/A/HTMLRendering 0x92d10000 - 0x92ddbfef com.apple.CoreServices.OSServices 359 (359) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices 0x92ddc000 - 0x92e5effb SecurityFoundation ??? (???) <2E1F1AF0-A258-D215-2600-5DF03896D1F1> /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation 0x92e81000 - 0x92e99ff7 com.apple.CFOpenDirectory 10.6 (10.6) /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory 0x92ed4000 - 0x92f3efe7 libstdc++.6.dylib 7.9.0 (compatibility 7.0.0) <411D87F4-B7E1-44EB-F201-F8B4F9227213> /usr/lib/libstdc++.6.dylib 0x92fb6000 - 0x930e4fe7 com.apple.CoreData 102.1 (251) <87FE6861-F2D6-773D-ED45-345272E56463> /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData 0x930e5000 - 0x93105fe7 libresolv.9.dylib 41.0.0 (compatibility 1.0.0) /usr/lib/libresolv.9.dylib 0x931ee000 - 0x9332aff7 com.apple.audio.toolbox.AudioToolbox 1.6.6 (1.6.6) <781018FB-474B-E09C-D419-5BFF80590A10> /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox 0x9332b000 - 0x93332ff7 com.apple.agl 3.0.12 (AGL-3.0.12) <61A74CE1-750D-9CAB-B780-306841739EE1> /System/Library/Frameworks/AGL.framework/Versions/A/AGL 0x93366000 - 0x9336cfe7 com.apple.CommerceCore 1.0 (9) <928FCA4F-1366-AE18-CF67-87C79F5DAC21> /System/Library/PrivateFrameworks/CommerceKit.framework/Versions/A/Frameworks/CommerceCore.framework/Versions/A/CommerceCore 0x9336f000 - 0x9344ffe7 com.apple.vImage 4.1 (4.1) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage 0x9345c000 - 0x93755fef com.apple.QuickTime 7.6.6 (1756.15) /System/Library/Frameworks/QuickTime.framework/Versions/A/QuickTime 0x93756000 - 0x93803fe7 libobjc.A.dylib 227.0.0 (compatibility 1.0.0) /usr/lib/libobjc.A.dylib 0x93804000 - 0x93854ff7 com.apple.framework.familycontrols 2.0.2 (2020) /System/Library/PrivateFrameworks/FamilyControls.framework/Versions/A/FamilyControls 0x93855000 - 0x93871fe3 com.apple.openscripting 1.3.1 (???) <2A748037-D1C0-6D47-2C4A-0562AF799AC9> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting 0x938a2000 - 0x938a5ffb com.apple.help 1.3.1 (41) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help 0x938a6000 - 0x938d9ff7 com.apple.AE 496.4 (496.4) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE 0x938da000 - 0x938daff7 com.apple.Accelerate.vecLib 3.6 (vecLib 3.6) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib 0x938db000 - 0x938e0ff7 com.apple.OpenDirectory 10.6 (10.6) /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory 0x938e1000 - 0x938f5ffb com.apple.speech.synthesis.framework 3.10.35 (3.10.35) <0DBE17D5-17A2-8A0E-8572-5A78408B41C9> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis 0x9391c000 - 0x93926fe7 com.apple.audio.SoundManager 3.9.3 (3.9.3) <5F494955-7290-2D91-DA94-44B590191771> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CarbonSound.framework/Versions/A/CarbonSound 0x93927000 - 0x939d1fe7 com.apple.CFNetwork 454.11.12 (454.11.12) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CFNetwork.framework/Versions/A/CFNetwork 0x93a8f000 - 0x93c49feb com.apple.ImageIO.framework 3.0.4 (3.0.4) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/ImageIO 0x93c75000 - 0x93c8afff com.apple.ImageCapture 6.0.2 (6.0.2) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture 0x93d92000 - 0x93dc3ff7 libGLImage.dylib ??? (???) <1AF72191-087A-5D75-B3B9-3F537315F635> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib 0x94846000 - 0x94846ff7 com.apple.CoreServices 44 (44) <51CFA89A-33DB-90ED-26A8-67D461718A4A> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices 0x94ad4000 - 0x94af3fe3 libexpat.1.dylib 7.2.0 (compatibility 7.0.0) <82E6F83F-9667-2E39-1D9D-4A49C642527D> /usr/lib/libexpat.1.dylib 0x94af4000 - 0x94b1cff7 libxslt.1.dylib 3.24.0 (compatibility 3.0.0) <769EF4B2-C1AD-73D5-AAAD-1564DAEA77AF> /usr/lib/libxslt.1.dylib 0x94b1d000 - 0x94b5fff7 libvDSP.dylib 268.0.1 (compatibility 1.0.0) <8A4721DE-25C4-C8AA-EA90-9DA7812E3EBA> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib 0x94b60000 - 0x94f97ff3 com.apple.RawCamera.bundle 3.6.4 (561) /System/Library/CoreServices/RawCamera.bundle/Contents/MacOS/RawCamera 0x95eec000 - 0x95f1fffb libTrueTypeScaler.dylib ??? (???) <574C2C51-65EC-7D2A-086D-C9312287DE22> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libTrueTypeScaler.dylib 0x95f20000 - 0x960a2fe7 libicucore.A.dylib 40.0.0 (compatibility 1.0.0) /usr/lib/libicucore.A.dylib 0x96158000 - 0x96159ff7 com.apple.audio.units.AudioUnit 1.6.6 (1.6.6) <253E9552-5CEA-0D5A-1EDA-3B8F669B79EA> /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit 0x96198000 - 0x963fdfeb com.apple.security 6.1.1 (37594) <251BA05D-6F3D-F687-77C2-15E52539F308> /System/Library/Frameworks/Security.framework/Versions/A/Security 0x963fe000 - 0x9650aff7 libGLProgrammability.dylib ??? (???) <2D172B4E-432F-D18E-EA99-3BD56DBE7649> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLProgrammability.dylib 0x9657b000 - 0x9657cff7 com.apple.TrustEvaluationAgent 1.1 (1) <2D970A9B-77E8-EDC0-BEC6-7580D78B2843> /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent 0x9657d000 - 0x9659cff7 com.apple.CoreVideo 1.6.2 (45.6) /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo 0x9659d000 - 0x965a0fe7 libmathCommon.A.dylib 315.0.0 (compatibility 1.0.0) <1622A54F-1A98-2CBE-B6A4-2122981A500E> /usr/lib/system/libmathCommon.A.dylib 0x9664b000 - 0x968befe7 com.apple.Foundation 6.6.6 (751.53) /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation 0x968bf000 - 0x96abdff3 com.apple.JavaScriptCore 6533.20 (6533.20.20) /System/Library/Frameworks/JavaScriptCore.framework/Versions/A/JavaScriptCore 0x96bcf000 - 0x96c13ff3 com.apple.coreui 2 (114) <2234855E-3BED-717F-0BFA-D1A289ECDBDA> /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI 0x96c6b000 - 0x96c6fff7 libGIF.dylib ??? (???) <447BC6E8-4C56-3D5D-983B-6BEA0D26F319> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib 0x96c70000 - 0x96d0dfe3 com.apple.LaunchServices 362.2 (362.2) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices 0x96f3a000 - 0x96f5eff7 libJPEG.dylib ??? (???) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib 0x96f74000 - 0x97022ff3 com.apple.ink.framework 1.3.3 (107) <233A981E-A2F9-56FB-8BDE-C2DEC3F20784> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink 0x97062000 - 0x970b3ff7 com.apple.HIServices 1.8.2 (???) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices 0x970f9000 - 0x970fbff7 com.apple.securityhi 4.0 (36638) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI 0x970fc000 - 0x970ffff7 libCoreVMClient.dylib ??? (???) <12EF6056-7AC7-6691-75A2-BD0675C56A35> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib 0x97100000 - 0x9714dfeb com.apple.DirectoryService.PasswordServerFramework 6.1 (6.1) <136BFA48-D456-B677-3B5D-40A6946C3A09> /System/Library/PrivateFrameworks/PasswordServer.framework/Versions/A/PasswordServer 0x9714e000 - 0x9725dfe7 com.apple.WebKit 6533.21 (6533.21.1) <4FBCE2F9-84EB-302C-FD1F-DAD2422A219E> /System/Library/Frameworks/WebKit.framework/Versions/A/WebKit 0x9726a000 - 0x97271ff3 com.apple.print.framework.Print 6.1 (237.1) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print 0x972e4000 - 0x9737fff7 com.apple.ApplicationServices.ATS 4.4 (???) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS 0x97380000 - 0x973ddff7 com.apple.framework.IOKit 2.0 (???) /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit 0x973de000 - 0x973ecfe7 libz.1.dylib 1.2.3 (compatibility 1.0.0) <33C1B260-ED05-945D-FC33-EF56EC791E2E> /usr/lib/libz.1.dylib 0x973ed000 - 0x973faff7 com.apple.NetFS 3.2.2 (3.2.2) /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS 0x973fb000 - 0x9748dfe7 com.apple.print.framework.PrintCore 6.3 (312.7) <7410D1B2-655D-68DA-D4B9-2C65747B6817> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore 0x9748e000 - 0x974d2fe7 com.apple.Metadata 10.6.3 (507.15) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata 0x974d3000 - 0x974d7ff7 IOSurface ??? (???) <235E7E3D-B6E5-0AAA-C41A-7AC1F54A7EBF> /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface 0x974d8000 - 0x976b4ffb libType1Scaler.dylib ??? (???) <494D1BE1-8395-9A53-1224-1CFD4236D40E> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libType1Scaler.dylib 0x976b5000 - 0x976edfe7 libncurses.5.4.dylib 5.4.0 (compatibility 5.4.0) <18AA1E55-D5F5-6343-80BF-8FA609C32BC5> /usr/lib/libncurses.5.4.dylib 0x976f5000 - 0x97738ff7 com.apple.NavigationServices 3.5.4 (182) <8DC6FD4A-6C74-9C23-A4C3-715B44A8D28C> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/NavigationServices.framework/Versions/A/NavigationServices 0x97739000 - 0x9783dfe7 libcrypto.0.9.8.dylib 0.9.8 (compatibility 0.9.8) /usr/lib/libcrypto.0.9.8.dylib 0x9783e000 - 0x97847ff7 com.apple.DiskArbitration 2.3 (2.3) /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration 0x97848000 - 0x978c2fff com.apple.audio.CoreAudio 3.2.6 (3.2.6) /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio 0x978ef000 - 0x97915ffb com.apple.DictionaryServices 1.1.2 (1.1.2) <43E1D565-6E01-3681-F2E5-72AE4C3A097A> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices 0x97916000 - 0x97a91fe7 com.apple.CoreFoundation 6.6.4 (550.42) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 0x97a92000 - 0x97dfdff7 com.apple.QuartzCore 1.6.3 (227.36) <8E927524-EB0A-D5BA-C2E4-FA26FE4C428A> /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore 0x97dfe000 - 0x97e5ffe7 com.apple.CoreText 3.151.8 (???) <6F5D6C49-4693-B9B7-6612-832E8F155747> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreText.framework/Versions/A/CoreText 0x97e87000 - 0x97f3efeb libFontParser.dylib ??? (???) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib 0x97f77000 - 0x9838dff7 libBLAS.dylib 219.0.0 (compatibility 1.0.0) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib 0x9838e000 - 0x983fdff7 libvMisc.dylib 268.0.1 (compatibility 1.0.0) <595A5539-9F54-63E6-7AAC-C04E1574B050> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib 0x983fe000 - 0x983feff7 com.apple.Accelerate 1.6 (Accelerate 1.6) <3891A689-4F38-FACD-38B2-4BF937DE30CF> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate 0x983ff000 - 0x98413fe7 libbsm.0.dylib ??? (???) <821E415B-6C42-D359-78FF-E892792F8C52> /usr/lib/libbsm.0.dylib 0x9854e000 - 0x98551ff7 libCGXType.A.dylib 545.0.0 (compatibility 64.0.0) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGXType.A.dylib 0x98552000 - 0x98653fe7 libxml2.2.dylib 10.3.0 (compatibility 10.0.0) /usr/lib/libxml2.2.dylib 0x98654000 - 0x98710fff com.apple.ColorSync 4.6.6 (4.6.6) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync 0x98711000 - 0x98711ff7 liblangid.dylib ??? (???) /usr/lib/liblangid.dylib 0x98712000 - 0x98718fff com.apple.CommonPanels 1.2.4 (91) <2438AF5D-067B-B9FD-1248-2C9987F360BA> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels 0x987c2000 - 0x987fdfeb libFontRegistry.dylib ??? (???) <4FB144ED-8AF9-27CF-B315-DCE5575D5231> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontRegistry.dylib 0x987fe000 - 0x987feff7 com.apple.vecLib 3.6 (vecLib 3.6) /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib 0x987ff000 - 0x9887ffeb com.apple.SearchKit 1.3.0 (1.3.0) <2F5DE102-A203-7905-7D12-FCBCF17BAEF8> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit 0x98880000 - 0x988c9fe7 libTIFF.dylib ??? (???) <5CE284EC-F637-EDBB-FDB3-61E86407CBB8> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib 0x988ca000 - 0x98983fe7 libsqlite3.dylib 9.6.0 (compatibility 9.0.0) <52438E77-55D1-C231-1936-76F1369518E4> /usr/lib/libsqlite3.dylib 0x98984000 - 0x989c5ff7 libRIP.A.dylib 545.0.0 (compatibility 64.0.0) <95079B56-0B7B-F114-5C43-5220DBE0FBB1> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libRIP.A.dylib 0x989c6000 - 0x98a03ff7 com.apple.SystemConfiguration 1.10.5 (1.10.2) <362DF639-6E5F-9371-9B99-81C581A8EE41> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration 0x98bb9000 - 0x98bc5ff7 libkxld.dylib ??? (???) <9D8378E0-1C58-EED8-EA00-F4515B8BE7A3> /usr/lib/system/libkxld.dylib 0x98bc6000 - 0x98be8fef com.apple.DirectoryService.Framework 3.6 (621.11) /System/Library/Frameworks/DirectoryService.framework/Versions/A/DirectoryService 0x98be9000 - 0x98cbafe3 ColorSyncDeprecated.dylib 4.6.0 (compatibility 1.0.0) <41417F73-42C5-FFC3-E7A1-EF94602CDCD6> /System/Library/Frameworks/ApplicationServices.framework/Frameworks/ColorSync.framework/Versions/A/Resources/ColorSyncDeprecated.dylib 0x98cbb000 - 0x98cbbff7 com.apple.ApplicationServices 38 (38) <8012B504-3D83-BFBB-DA65-065E061CFE03> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices 0x98d04000 - 0x98d04ff7 com.apple.Carbon 150 (152) <734BDB59-8B13-54FA-0653-AA8623DF9846> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon 0x98d60000 - 0x98d60ff7 com.apple.Cocoa 6.6 (???) /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa 0x98d61000 - 0x99196ff7 libLAPACK.dylib 219.0.0 (compatibility 1.0.0) <5E2D2283-57DE-9A49-1DB0-CD027FEFA6C2> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib 0x99197000 - 0x991a9ff7 com.apple.MultitouchSupport.framework 207.10 (207.10) <32CE2895-DAF0-2137-F9BE-8150359F43A1> /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport 0x991bd000 - 0x999ac557 com.apple.CoreGraphics 1.545.0 (???) <8A4CB0D9-1001-0F62-4DA4-B8AB3B45E226> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics 0x99a06000 - 0x99a17ff7 com.apple.LangAnalysis 1.6.6 (1.6.6) <3036AD83-4F1D-1028-54EE-54165E562650> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis 0xffff0000 - 0xffff1fff libSystem.B.dylib ??? (???) /usr/lib/libSystem.B.dylib Model: MacBookPro6,2, BootROM MBP61.0057.B0C, 2 processors, Intel Core i5, 2.4 GHz, 8 GB, SMC 1.58f16 Graphics: NVIDIA GeForce GT 330M, NVIDIA GeForce GT 330M, PCIe, 256 MB Graphics: Intel HD Graphics, Intel HD Graphics, Built-In, 288 MB Memory Module: global_name AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x93), Broadcom BCM43xx 1.0 (5.10.131.36.9) Bluetooth: Version 2.4.0f1, 2 service, 12 devices, 1 incoming serial ports Network Service: AirPort, AirPort, en1 Serial ATA Device: Hitachi HTS545032B9SA02, 298.09 GB Serial ATA Device: MATSHITADVD-R UJ-898 USB Device: Hub, 0x0424 (SMSC), 0x2514, 0xfa100000 USB Device: Internal Memory Card Reader, 0x05ac (Apple Inc.), 0x8403, 0xfa130000 USB Device: Apple Internal Keyboard / Trackpad, 0x05ac (Apple Inc.), 0x0237, 0xfa120000 USB Device: BRCM2070 Hub, 0x0a5c (Broadcom Corp.), 0x4500, 0xfa110000 USB Device: Bluetooth USB Host Controller, 0x05ac (Apple Inc.), 0x8218, 0xfa113000 USB Device: Hub, 0x0424 (SMSC), 0x2514, 0xfd100000 USB Device: IR Receiver, 0x05ac (Apple Inc.), 0x8242, 0xfd120000 USB Device: Built-in iSight, 0x05ac (Apple Inc.), 0x8507, 0xfd110000 From hm@REDACTED Fri May 13 14:53:13 2011 From: hm@REDACTED (=?ISO-8859-1?Q?H=E5kan_Mattsson?=) Date: Fri, 13 May 2011 14:53:13 +0200 Subject: [erlang-questions] Reltool, system crashes and ports In-Reply-To: <546897070.176471305290181612.JavaMail.root@zimbra> References: <1339983442.176451305290146056.JavaMail.root@zimbra> <546897070.176471305290181612.JavaMail.root@zimbra> Message-ID: On Fri, May 13, 2011 at 2:36 PM, Robert Virding wrote: > I was just gently pointing out that wx, and therefore reltool, is not > very stable on a common platform. A corollary to this is that it might > not be a good thing to base new tools on wx until it is stable, and > definitely not convert old, functioning tools to use it. > > The main point I was (gently) trying to make is that it is a Good Thing > when building reliable systems to avoid as much as possible including > things in the base system which aren't absolutely necessary and which > can be run in other OS processes. It lessens the number of things which > can cause the whole system to crash and increases the number of things > which you can safely use even if they might crash. In this case it was a > graphics interface which caused the crash! So in this context wx as it > stands is not safe for use in reliable systems. I agree that it is a pity that wx is not as stable on Mac as on other platforms. But do you not exaggerate a bit? The graphical tools in Erlang/OTP are mostly used during development and most of them can be run on nodes separate from the mission critical live nodes. /H?kan From watson.timothy@REDACTED Fri May 13 14:56:58 2011 From: watson.timothy@REDACTED (Tim Watson) Date: Fri, 13 May 2011 13:56:58 +0100 Subject: [erlang-questions] Determine if a binary is ref-counted in port driver code In-Reply-To: <353829845.176321305289087513.JavaMail.root@zimbra> References: <431849068.176251305288848319.JavaMail.root@zimbra> <353829845.176321305289087513.JavaMail.root@zimbra> Message-ID: On 13 May 2011 13:18, Gustav Simonsson wrote: > > This post talks about how the SysIOVec field in ErlIOVec gets its value depending > on the properties of the binaries in the io list: > > http://www1.erlang.org/pipermail/erlang-questions/2002-October/005859.html > and the reply > http://www1.erlang.org/pipermail/erlang-questions/2002-October/005860.html > > It's from 2002 so the behaviour might be different, but the code > referenced in the post does checks on the binaries in the io list in order to determine what todo. > > See erts_write_to_port (line 1085) and io_list_vec_len (line 999) in > https://github.com/erlang/otp/blob/dev/erts/emulator/beam/io.c > Brilliant - I'll go check those out. Thanks! From dmercer@REDACTED Fri May 13 15:25:46 2011 From: dmercer@REDACTED (David Mercer) Date: Fri, 13 May 2011 08:25:46 -0500 Subject: [erlang-questions] Function Declaration Syntax In-Reply-To: References: Message-ID: <005701cc1171$45f543e0$d1dfcba0$@com> On Friday, May 13, 2011, Justus wrote: > I come to a question on function declaration syntax: why does function > name appear in each clause? > > Name(Pattern11,...,Pattern1N) [when GuardSeq1] -> > Body1; > ...; > Name(PatternK1,...,PatternKN) [when GuardSeqK] -> > BodyK. > > It does not provide any information, except that one might make silly > mistakes. Syntactic salt? http://en.wikipedia.org/wiki/Syntactic_salt#Syntactic_salt Cheers, DBM From the.malkolm@REDACTED Fri May 13 15:34:21 2011 From: the.malkolm@REDACTED (Alexander Krasnukhin) Date: Fri, 13 May 2011 15:34:21 +0200 Subject: [erlang-questions] Function Declaration Syntax In-Reply-To: References: Message-ID: Think about it not as whole function but as set of clauses. It make sense this way. On Fri, May 13, 2011 at 11:43 AM, Justus wrote: > Hi all, > > I come to a question on function declaration syntax: why does function > name appear in each clause? > > Name(Pattern11,...,Pattern1N) [when GuardSeq1] -> > Body1; > ...; > Name(PatternK1,...,PatternKN) [when GuardSeqK] -> > BodyK. > > It does not provide any information, except that one might make silly > mistakes. > > If omitting it, a new problem is how to indent clauses properly and > beautifully. > > Name(Pattern11,...,Pattern1N) [when GuardSeq1] -> > Body1; > (PatternK1,...,PatternKN) [when GuardSeqK] -> > BodyK. > > -- > Best Regards, > Justus > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Regards, Alexander -------------- next part -------------- An HTML attachment was scrubbed... URL: From boris.muehmer@REDACTED Fri May 13 16:40:55 2011 From: boris.muehmer@REDACTED (=?UTF-8?Q?Boris_M=C3=BChmer?=) Date: Fri, 13 May 2011 16:40:55 +0200 Subject: [erlang-questions] compiling R14B02 with WX support on Ubuntu 11.04 In-Reply-To: References: Message-ID: Besides, could you check "wx:demo()", please? Especially the "gl" part... It crashes on my system. If it crashes on Your system as well, I would submit a bug report... - boris 2011/5/13 Cyryl P?otnicki-Chudyk : > 2011/5/13 Boris M?hmer : >> Maybe have a look at: >> >> ? ?http://boris.muehmer.de/2011/05/07/installing-erlangotp-r14b02-on-ubuntu-11-04-from-source-tarball/ >> >> And compare it to what You have done so far. >> >> > > Thanks for the link ! > It seems that I've missed the 'libglu-dev' as the dependency of the wx. > Btw my apt-get said that there's no such package, however it selected > the similar one which seems to get the job done. i.e. I don't get the > configure warning at this time, I'll try compiling some WX examples > later on. > > Here's the apt-get output: > 'Note, selecting 'libglu1-mesa-dev' instead of 'libglu-dev' > > > -- > cyryl > From cyplo@REDACTED Fri May 13 16:44:46 2011 From: cyplo@REDACTED (=?UTF-8?Q?Cyryl_P=C5=82otnicki=2DChudyk?=) Date: Fri, 13 May 2011 16:44:46 +0200 Subject: [erlang-questions] compiling R14B02 with WX support on Ubuntu 11.04 In-Reply-To: References: Message-ID: 2011/5/13 Boris M?hmer : > Besides, could you check "wx:demo()", please? > > Especially the "gl" part... It crashes on my system. > > If it crashes on Your system as well, I would submit a bug report... > > works, except the gl part wchich crashes the whole emulator 1> wx:demo(). {wx_ref,35,wxFrame,<0.34.0>} 2> (Erlang:24191): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -5 and height 17 (Erlang:24191): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -5 and height 17 (Erlang:24191): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -5 and height 17 Segmentation fault -- cyryl From attila.r.nohl@REDACTED Fri May 13 17:01:26 2011 From: attila.r.nohl@REDACTED (Attila Rajmund Nohl) Date: Fri, 13 May 2011 17:01:26 +0200 Subject: [erlang-questions] Function Declaration Syntax In-Reply-To: References: Message-ID: The (usual) problem is that this is not consistent. You have to write the function name for different function clauses, but must not write the 'fun' for different clauses in anonymous functions. I would prefer the 'fun' anu anonymous functions too. 2011/5/13, Alexander Krasnukhin : > Think about it not as whole function but as set of clauses. It make sense > this way. > > On Fri, May 13, 2011 at 11:43 AM, Justus wrote: > >> Hi all, >> >> I come to a question on function declaration syntax: why does function >> name appear in each clause? >> >> Name(Pattern11,...,Pattern1N) [when GuardSeq1] -> >> Body1; >> ...; >> Name(PatternK1,...,PatternKN) [when GuardSeqK] -> >> BodyK. >> >> It does not provide any information, except that one might make silly >> mistakes. >> >> If omitting it, a new problem is how to indent clauses properly and >> beautifully. >> >> Name(Pattern11,...,Pattern1N) [when GuardSeq1] -> >> Body1; >> (PatternK1,...,PatternKN) [when GuardSeqK] -> >> BodyK. >> >> -- >> Best Regards, >> Justus >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > > > -- > Regards, > Alexander > From robert.virding@REDACTED Fri May 13 17:03:21 2011 From: robert.virding@REDACTED (Robert Virding) Date: Fri, 13 May 2011 15:03:21 +0000 (GMT) Subject: [erlang-questions] Reltool, system crashes and ports In-Reply-To: <1834583630.176881305298500296.JavaMail.root@zimbra> Message-ID: <1585879380.176901305299001597.JavaMail.root@zimbra> ----- "H?kan Mattsson" wrote: > I agree that it is a pity that wx is not as stable on Mac as on other > platforms. > But do you not exaggerate a bit? The graphical tools in Erlang/OTP > are mostly used during development and most of them can be run on > nodes separate from the mission critical live nodes. That's true for the tools, but if I want to use wx directly in my systems then I will have to be careful how and where I do it as wx is run internally and can crash the system. Running wx on separate node is a bit funny in a way as it is almost like running it in a port process. Robert From ivan@REDACTED Fri May 13 17:45:10 2011 From: ivan@REDACTED (Ivan Uemlianin) Date: Fri, 13 May 2011 16:45:10 +0100 Subject: [erlang-questions] SOLVED: Re: how to connect erlang nodes through an uncontrolled firewall In-Reply-To: <20110510204557.GA830@hanele.lan> References: <4DC94A8D.6000501@llaisdy.com> <20110510204557.GA830@hanele.lan> Message-ID: <4DCD5206.3030606@llaisdy.com> Thanks All. I should have just tried it: it worked without anything fancy once I'd got the ports set up on the remote end. So, I now have appmon and pman listening to a VM running on a remote machine. Very convenient and nice. Best wishes Ivan On 10/05/2011 21:45, Jachym Holecek wrote: > # Ivan Uemlianin 2011-05-10: >> I'd like to connect a couple of erlang nodes together, one "here", one >> on a remote machine. There are two firewalls in the way: one on the >> remote machine, one local. >> >> The remote firewall I can ask for ports to be opened. I've read that >> 4369 for epmd and one other port are required (the second can be >> assigned at runtime using sth like >> >> erl -name qweasd -kernel inet_dist_listen_min 9001 >> inet_dist_listen_max 9001 [1] >> >> The local firewall is fixed, in the sense that I don't think I can ask >> for ports to be opened and so on (I'm in a shared office building with >> provided internet access). >> >> Is there anything I can do at this end to open a connection? I can ssh >> out the the remote machine. Can I have the nodes connect over ssh? > > You can forward arbitrary ports via 'ssh -L ...' -- never tried that for > Erlang distribution though, so just a pointer for experiment really. If > you have sufficient control over the remote server, openvpn is another > quite hassle-free option for you. > > HTH, > -- Jachym -- ============================================================ Ivan A. Uemlianin Speech Technology Research and Development ivan@REDACTED www.llaisdy.com llaisdy.wordpress.com www.linkedin.com/in/ivanuemlianin "Froh, froh! Wie seine Sonnen, seine Sonnen fliegen" (Schiller, Beethoven) ============================================================ From ciprian.craciun@REDACTED Fri May 13 20:46:51 2011 From: ciprian.craciun@REDACTED (Ciprian Dorin Craciun) Date: Fri, 13 May 2011 21:46:51 +0300 Subject: [erlang-questions] Best practices for handling invalid / unexpected messages Message-ID: Hello all! Lately I've started programming a bit more seriously in Erlang, and after creating a few `gen_server` or `gen_fsm` components, I've started wondering what is the best way to handle unexpected or invalid requests / messages. (For example in `handle_call`, or `handle_info` or state handlers.) (By invalid requests I mean those that have the correct form (i.e. a tuple `{add, A, B}`) but invalid syntax (i.e. `A` is an atom); by unexpected messages I mean those that fail to even loosely match a valid pattern (i.e. `{some_unrecognized_operation, A, B}`.) I think of three possibilities: * reply back with an error: ~~~~ handle_call (Request, _Sender, State) -> {reply, {error, {invalid_request, Request}}, State}. ~~~~ * exit with an error; ~~~~ handle_call (Request, _Sender, State) -> {stop, {error, {invalid_request, Request}}, State}. ~~~~ * don't even create a special catch-all case and just let the process fail with `function_clause` error; Now each of these have advantages or disadvantages: * the first one is "polite" to the caller, letting him retry, but could lead to hidden bugs if the caller doesn't check the return term; * the second one I think fits more the Erlang philosophy of "let-it-crash", but could lead to state loss (i.e. an ETS table); * the last one I consider to be just rude as it doesn't give any information on why it failed; Furthermore, let's say a process depends in his operation on another process, should it link the dependency process, should it monitor, or should it just fail on call? So I ask the other Erlang developers how do they handle these situations? Thanks, Ciprian. From spawn.think@REDACTED Fri May 13 21:57:39 2011 From: spawn.think@REDACTED (Ahmed Omar) Date: Fri, 13 May 2011 21:57:39 +0200 Subject: [erlang-questions] Best practices for handling invalid / unexpected messages In-Reply-To: References: Message-ID: Hello Ciprian, IMHO A) Define the "Caller" : i believe you need to make a distinction between the boundaries of your system and the internals. - On the boundaries, when other systems can feed data into yours, it's better to "validate" the inputs. - Introduce client APIs for your gen_server, wrapping/abstracting the actual gen_server:call - Do the validation in these APIs, so the crash will be in the client process scope. For the gen_server callbacks itself (handle_call, handle_cast, handle_info), i would vote for letting it crash if something wrong got there, because 1) Makes your code cleaner, more neat and easier to debug 2) Doesn't hide bugs (Why a wrong request was made, and why it was not validated on the boundaries, also if the caller doesn't check replies, ..etc) B) Other dependent processes : It depends on your design, services provided by that gen_server and kind of state it keeps. In some cases, the processes needs to be restarted along with it (maybe to do initializations all over again), in other cases they don't need that. Define your case, and put the supervision tree that suites your needs. I hope this helps On Fri, May 13, 2011 at 8:46 PM, Ciprian Dorin Craciun < ciprian.craciun@REDACTED> wrote: > Hello all! > > Lately I've started programming a bit more seriously in Erlang, > and after creating a few `gen_server` or `gen_fsm` components, I've > started wondering what is the best way to handle unexpected or invalid > requests / messages. (For example in `handle_call`, or `handle_info` > or state handlers.) (By invalid requests I mean those that have the > correct form (i.e. a tuple `{add, A, B}`) but invalid syntax (i.e. `A` > is an atom); by unexpected messages I mean those that fail to even > loosely match a valid pattern (i.e. `{some_unrecognized_operation, A, > B}`.) > > I think of three possibilities: > * reply back with an error: > ~~~~ > handle_call (Request, _Sender, State) -> {reply, {error, > {invalid_request, Request}}, State}. > ~~~~ > * exit with an error; > ~~~~ > handle_call (Request, _Sender, State) -> {stop, {error, > {invalid_request, Request}}, State}. > ~~~~ > * don't even create a special catch-all case and just let the > process fail with `function_clause` error; > > Now each of these have advantages or disadvantages: > * the first one is "polite" to the caller, letting him retry, but > could lead to hidden bugs if the caller doesn't check the return term; > * the second one I think fits more the Erlang philosophy of > "let-it-crash", but could lead to state loss (i.e. an ETS table); > * the last one I consider to be just rude as it doesn't give any > information on why it failed; > > Furthermore, let's say a process depends in his operation on > another process, should it link the dependency process, should it > monitor, or should it just fail on call? > > So I ask the other Erlang developers how do they handle these > situations? > > Thanks, > Ciprian. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think -------------- next part -------------- An HTML attachment was scrubbed... URL: From freza@REDACTED Fri May 13 21:59:20 2011 From: freza@REDACTED (Jachym Holecek) Date: Fri, 13 May 2011 20:59:20 +0100 Subject: [erlang-questions] Best practices for handling invalid / unexpected messages In-Reply-To: References: Message-ID: <20110513195920.GA1721@hanele.lan> # Ciprian Dorin Craciun 2011-05-13: > Lately I've started programming a bit more seriously in Erlang, > and after creating a few `gen_server` or `gen_fsm` components, I've > started wondering what is the best way to handle unexpected or invalid > requests / messages. [...] > > I think of three possibilities: > * reply back with an error: Yep, this is what I do: handle_call(_, _, State) -> {reply, {error, bad_request}, State}. handle_info(_, State) -> {noreply, State}. It's similar with gen_fsm & custom processes. > Now each of these have advantages or disadvantages: > > * the first one is "polite" to the caller, letting him retry, > but could lead to hidden bugs if the caller doesn't check > the return term; It also helps forward-compatibility in presence of hot code upgrades. > Furthermore, let's say a process depends in his operation on > another process, should it link the dependency process, should it > monitor, or should it just fail on call? Depends on how tightly they're bound together. Linking them means "one can't live without the other even for a second", monitoring means "one is vaguely interested if the other is still alive" (often to clean up some mess when the other dies), fail on call means "ok, I need you to handle my request now, but generally I don't really care about you". The last option is by far the most common, the other two are employed tactically in cases where it matters. HTH, -- Jachym From ciprian.craciun@REDACTED Fri May 13 22:19:42 2011 From: ciprian.craciun@REDACTED (Ciprian Dorin Craciun) Date: Fri, 13 May 2011 23:19:42 +0300 Subject: [erlang-questions] Best practices for handling invalid / unexpected messages In-Reply-To: References: Message-ID: On Fri, May 13, 2011 at 22:57, Ahmed Omar wrote: > Hello Ciprian, > IMHO > A) Define the "Caller" : > ?i believe you need to make a distinction between the boundaries of your > system and the internals. > - On the boundaries, when other systems can feed data into yours, it's > better to "validate" the inputs. > - Introduce client APIs for your gen_server, wrapping/abstracting the actual > gen_server:call Indeed I wasn't to specific about the purpose of these processes. I was referring to the internal application processes, those which are shielded from the "real" callers through a module / process that exposes a REST interface or a RPC system where I try to validate the inputs and give back errors as you've described. > - Do the validation in these APIs, so the crash will be in the client > process scope. About the `gen_server:call` wrappers, should I really do any validation here if the exposed API is an "internal" one (as described above not directly exposed to the "network")? It could amount to a bit of overhead, especially if the validation is not a trivial one and involves the inspection of a deep structure? > For the gen_server callbacks itself (handle_call, handle_cast, handle_info), > i would vote for letting it crash if something wrong got there, because > 1) Makes your code cleaner, more neat and easier to debug > 2) Doesn't hide bugs (Why a wrong request was made, and why it was not > validated on the boundaries, also if the caller doesn't check replies, > ..etc) Ok. > B) Other dependent processes : > It depends on your design, services provided by that gen_server and kind of > state it keeps. In some cases, the processes needs to be restarted along > with it (maybe to do initializations all over again), in other cases they > don't need that. Define your case, and put the supervision tree that suites > your needs. Indeed a supervisor tree helps if both the dependent and dependency process are created by me and part of the same application. But if one process is provided by another application I can't resort anymore to `one_for_all` option, but instead I need to link the process. The only problem is that in this case the link is not quite bi-directional: i.e. if my dependency process fails then all the dependent processes should be restarted, but if only a dependent process fails, then the dependency could live on. Therefore I think monitors (inside the dependent process) could be a better solution, but working with monitors is not as easy as linking. > I hope this helps Thanks for your reply, it confirmed / extended my initial hunches. Ciprian. > On Fri, May 13, 2011 at 8:46 PM, Ciprian Dorin Craciun > wrote: >> >> ? ?Hello all! >> >> ? ?Lately I've started programming a bit more seriously in Erlang, >> and after creating a few `gen_server` or `gen_fsm` components, I've >> started wondering what is the best way to handle unexpected or invalid >> requests / messages. (For example in `handle_call`, or `handle_info` >> or state handlers.) (By invalid requests I mean those that have the >> correct form (i.e. a tuple `{add, A, B}`) but invalid syntax (i.e. `A` >> is an atom); by unexpected messages I mean those that fail to even >> loosely match a valid pattern (i.e. `{some_unrecognized_operation, A, >> B}`.) >> >> ? ?I think of three possibilities: >> ? ?* reply back with an error: >> ~~~~ >> handle_call (Request, _Sender, State) -> {reply, {error, >> {invalid_request, Request}}, State}. >> ~~~~ >> ? ?* exit with an error; >> ~~~~ >> handle_call (Request, _Sender, State) -> {stop, {error, >> {invalid_request, Request}}, State}. >> ~~~~ >> ? ?* don't even create a special catch-all case and just let the >> process fail with `function_clause` error; >> >> ? ?Now each of these have advantages or disadvantages: >> ? ?* the first one is "polite" to the caller, letting him retry, but >> could lead to hidden bugs if the caller doesn't check the return term; >> ? ?* the second one I think fits more the Erlang philosophy of >> "let-it-crash", but could lead to state loss (i.e. an ETS table); >> ? ?* the last one I consider to be just rude as it doesn't give any >> information on why it failed; >> >> ? ?Furthermore, let's say a process depends in his operation on >> another process, should it link the dependency process, should it >> monitor, or should it just fail on call? >> >> ? ?So I ask the other Erlang developers how do they handle these >> situations? >> >> ? ?Thanks, >> ? ?Ciprian. >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > > > -- > Best Regards, > - Ahmed Omar > http://nl.linkedin.com/in/adiaa > Follow me on twitter > @spawn_think From erlang@REDACTED Fri May 13 22:20:42 2011 From: erlang@REDACTED (Joe Armstrong) Date: Fri, 13 May 2011 22:20:42 +0200 Subject: [erlang-questions] Best practices for handling invalid / unexpected messages In-Reply-To: <20110513195920.GA1721@hanele.lan> References: <20110513195920.GA1721@hanele.lan> Message-ID: No easy answer: During development: Crash loudly - print lots of information about why you crashed do init:stop() or erlang:halt() *force* the programmer to fix the code During production Crash silently - put lots of error in the log and send rude email to programmer if you can recover do so. If you cannot recover tell the user as politely as possible. *never* present the user with internal error message (this is most unprofessional) What you do with an error thus depends upon the context where it occurs - basically tell the programmer the truth and give them all the info needed to fix the error, while apologizing to the end user ... send an email to the project manager telling the code is broken if you want the programmer to fix it :-) /Joe On Fri, May 13, 2011 at 9:59 PM, Jachym Holecek wrote: > # Ciprian Dorin Craciun 2011-05-13: > > Lately I've started programming a bit more seriously in Erlang, > > and after creating a few `gen_server` or `gen_fsm` components, I've > > started wondering what is the best way to handle unexpected or invalid > > requests / messages. [...] > > > > I think of three possibilities: > > * reply back with an error: > > Yep, this is what I do: > > handle_call(_, _, State) -> > {reply, {error, bad_request}, State}. > > handle_info(_, State) -> > {noreply, State}. > > It's similar with gen_fsm & custom processes. > > > Now each of these have advantages or disadvantages: > > > > * the first one is "polite" to the caller, letting him retry, > > but could lead to hidden bugs if the caller doesn't check > > the return term; > > It also helps forward-compatibility in presence of hot code upgrades. > > > Furthermore, let's say a process depends in his operation on > > another process, should it link the dependency process, should it > > monitor, or should it just fail on call? > > Depends on how tightly they're bound together. Linking them means "one > can't live without the other even for a second", monitoring means "one > is vaguely interested if the other is still alive" (often to clean up > some mess when the other dies), fail on call means "ok, I need you to > handle my request now, but generally I don't really care about you". > > The last option is by far the most common, the other two are employed > tactically in cases where it matters. > > HTH, > -- Jachym > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Fri May 13 22:23:25 2011 From: erlang@REDACTED (Joe Armstrong) Date: Fri, 13 May 2011 22:23:25 +0200 Subject: [erlang-questions] Function Declaration Syntax In-Reply-To: References: Message-ID: No good reason. Erlang evolved from Prolog and that how it was done in Prolog no deep thought was involved .. /Joe On Fri, May 13, 2011 at 11:43 AM, Justus wrote: > Hi all, > > I come to a question on function declaration syntax: why does function > name appear in each clause? > > Name(Pattern11,...,Pattern1N) [when GuardSeq1] -> > Body1; > ...; > Name(PatternK1,...,PatternKN) [when GuardSeqK] -> > BodyK. > > It does not provide any information, except that one might make silly > mistakes. > > If omitting it, a new problem is how to indent clauses properly and > beautifully. > > Name(Pattern11,...,Pattern1N) [when GuardSeq1] -> > Body1; > (PatternK1,...,PatternKN) [when GuardSeqK] -> > BodyK. > > -- > Best Regards, > Justus > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ciprian.craciun@REDACTED Fri May 13 22:24:39 2011 From: ciprian.craciun@REDACTED (Ciprian Dorin Craciun) Date: Fri, 13 May 2011 23:24:39 +0300 Subject: [erlang-questions] Best practices for handling invalid / unexpected messages In-Reply-To: <20110513195920.GA1721@hanele.lan> References: <20110513195920.GA1721@hanele.lan> Message-ID: On Fri, May 13, 2011 at 22:59, Jachym Holecek wrote: > # Ciprian Dorin Craciun 2011-05-13: >> ? ? Lately I've started programming a bit more seriously in Erlang, >> and after creating a few `gen_server` or `gen_fsm` components, I've >> started wondering what is the best way to handle unexpected or invalid >> requests / messages. [...] >> >> ? ? I think of three possibilities: >> ? ? * reply back with an error: > > Yep, this is what I do: > > ?handle_call(_, _, State) -> > ? ? ?{reply, {error, bad_request}, State}. > > ?handle_info(_, State) -> > ? ? ?{noreply, State}. > > It's similar with gen_fsm & custom processes. The main problem here is that it silently can "swallow" miscommunication bugs. >> ? ? Now each of these have advantages or disadvantages: >> >> ? ? * the first one is "polite" to the caller, letting him retry, >> ? ? ? but could lead to hidden bugs if the caller doesn't check >> ? ? ? the return term; > > It also helps forward-compatibility in presence of hot code upgrades. Hm... Code upgrades could be a valid reason. But then the callee should have also been updated... >> ? ? Furthermore, let's say a process depends in his operation on >> another process, should it link the dependency process, should it >> monitor, or should it just fail on call? > > Depends on how tightly they're bound together. Linking them means "one > can't live without the other even for a second", monitoring means "one > is vaguely interested if the other is still alive" (often to clean up > some mess when the other dies), fail on call means "ok, I need you to > handle my request now, but generally I don't really care about you". > > The last option is by far the most common, the other two are employed > tactically in cases where it matters. Indeed I'm speaking about an asymmetric relation; in general I'm speaking about a server and it's clients, the server can live if one client crashes, but none of the clients can without the server. My problem is monitoring vs linking. Linking seems more "bullet-proof" than "monitoring"... > HTH, > ? ? ? ?-- Jachym Thanks for your feedback. Ciprian. From spawn.think@REDACTED Fri May 13 22:33:00 2011 From: spawn.think@REDACTED (Ahmed Omar) Date: Fri, 13 May 2011 22:33:00 +0200 Subject: [erlang-questions] Best practices for handling invalid / unexpected messages In-Reply-To: References: Message-ID: On Fri, May 13, 2011 at 10:19 PM, Ciprian Dorin Craciun < ciprian.craciun@REDACTED> wrote: > On Fri, May 13, 2011 at 22:57, Ahmed Omar wrote: > > Hello Ciprian, > > IMHO > > A) Define the "Caller" : > > i believe you need to make a distinction between the boundaries of your > > system and the internals. > > - On the boundaries, when other systems can feed data into yours, it's > > better to "validate" the inputs. > > - Introduce client APIs for your gen_server, wrapping/abstracting the > actual > > gen_server:call > > Indeed I wasn't to specific about the purpose of these processes. > I was referring to the internal application processes, those which are > shielded from the "real" callers through a module / process that > exposes a REST interface or a RPC system where I try to validate the > inputs and give back errors as you've described. > > > > - Do the validation in these APIs, so the crash will be in the client > > process scope. > > About the `gen_server:call` wrappers, should I really do any > validation here if the exposed API is an "internal" one (as described > above not directly exposed to the "network")? It could amount to a bit > of overhead, especially if the validation is not a trivial one and > involves the inspection of a deep structure? > > No. In case data is from inside your system, you might assume it's correct. (specially if validation will cause too much overhead). > > > For the gen_server callbacks itself (handle_call, handle_cast, > handle_info), > > i would vote for letting it crash if something wrong got there, because > > 1) Makes your code cleaner, more neat and easier to debug > > 2) Doesn't hide bugs (Why a wrong request was made, and why it was not > > validated on the boundaries, also if the caller doesn't check replies, > > ..etc) > > Ok. > > > > B) Other dependent processes : > > It depends on your design, services provided by that gen_server and kind > of > > state it keeps. In some cases, the processes needs to be restarted along > > with it (maybe to do initializations all over again), in other cases they > > don't need that. Define your case, and put the supervision tree that > suites > > your needs. > > Indeed a supervisor tree helps if both the dependent and > dependency process are created by me and part of the same application. > But if one process is provided by another application I can't resort > anymore to `one_for_all` option, but instead I need to link the > process. The only problem is that in this case the link is not quite > bi-directional: i.e. if my dependency process fails then all the > dependent processes should be restarted, but if only a dependent > process fails, then the dependency could live on. Therefore I think > monitors (inside the dependent process) could be a better solution, > but working with monitors is not as easy as linking. > > > Actually monitors are not that hard at all, you just need to understand them correctly. You still can use links and trap exit on your main process, but i personally don't prefer this way (only a preference) I would recommend checking LYSE http://learnyousomeerlang.com/errors-and-processes > > I hope this helps > > Thanks for your reply, it confirmed / extended my initial hunches. > > Ciprian. > > > > On Fri, May 13, 2011 at 8:46 PM, Ciprian Dorin Craciun > > wrote: > >> > >> Hello all! > >> > >> Lately I've started programming a bit more seriously in Erlang, > >> and after creating a few `gen_server` or `gen_fsm` components, I've > >> started wondering what is the best way to handle unexpected or invalid > >> requests / messages. (For example in `handle_call`, or `handle_info` > >> or state handlers.) (By invalid requests I mean those that have the > >> correct form (i.e. a tuple `{add, A, B}`) but invalid syntax (i.e. `A` > >> is an atom); by unexpected messages I mean those that fail to even > >> loosely match a valid pattern (i.e. `{some_unrecognized_operation, A, > >> B}`.) > >> > >> I think of three possibilities: > >> * reply back with an error: > >> ~~~~ > >> handle_call (Request, _Sender, State) -> {reply, {error, > >> {invalid_request, Request}}, State}. > >> ~~~~ > >> * exit with an error; > >> ~~~~ > >> handle_call (Request, _Sender, State) -> {stop, {error, > >> {invalid_request, Request}}, State}. > >> ~~~~ > >> * don't even create a special catch-all case and just let the > >> process fail with `function_clause` error; > >> > >> Now each of these have advantages or disadvantages: > >> * the first one is "polite" to the caller, letting him retry, but > >> could lead to hidden bugs if the caller doesn't check the return term; > >> * the second one I think fits more the Erlang philosophy of > >> "let-it-crash", but could lead to state loss (i.e. an ETS table); > >> * the last one I consider to be just rude as it doesn't give any > >> information on why it failed; > >> > >> Furthermore, let's say a process depends in his operation on > >> another process, should it link the dependency process, should it > >> monitor, or should it just fail on call? > >> > >> So I ask the other Erlang developers how do they handle these > >> situations? > >> > >> Thanks, > >> Ciprian. > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questions@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > > -- > > Best Regards, > > - Ahmed Omar > > http://nl.linkedin.com/in/adiaa > > Follow me on twitter > > @spawn_think > -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think -------------- next part -------------- An HTML attachment was scrubbed... URL: From ciprian.craciun@REDACTED Fri May 13 22:34:11 2011 From: ciprian.craciun@REDACTED (Ciprian Dorin Craciun) Date: Fri, 13 May 2011 23:34:11 +0300 Subject: [erlang-questions] Best practices for handling invalid / unexpected messages In-Reply-To: References: <20110513195920.GA1721@hanele.lan> Message-ID: On Fri, May 13, 2011 at 23:20, Joe Armstrong wrote: > No easy answer: > > During development: > > ??? Crash loudly - print lots of information about why you crashed > ??? do init:stop() or erlang:halt() *force* the programmer to fix the code > > During production > > ??? Crash silently - put lots of error in the log and send rude email to > programmer > ??? if you can recover do so. If you cannot recover tell the user as > politely as possible. > ??? *never* present the user with internal error message (this is most > unprofessional) Interesting. The only problem is how to achieve this without writing too much boilerplate code? For example it would have been nice to have a return value like `{error, Reason, NewState}` from callbacks like `handle_call`, etc.; which depending on the running environment either "dispatches" `{reply, {error, Reason}, NewState}`, or `{stop, {error, Reason}, NewState}`. But as such a solution doesn't exist I could just create three generic functions like `handle_call_error (Reason, NewState)` that is called from within `handle_call` in a tail position, thus achieving the same outcome. Any other ideas? > What you do with an error thus depends upon the context where it occurs - > basically > tell the programmer the truth and give them all the info needed to fix the > error, while > apologizing to the end user ... send an email to the project manager telling > the code > is broken if you want the programmer to fix it :-) > > /Joe A similar approach is done in `web2py` I think, where each unhandled exception that bubbles outside the callback automatically creates a bug ticket :) Thanks! Ciprian. > On Fri, May 13, 2011 at 9:59 PM, Jachym Holecek > wrote: >> >> # Ciprian Dorin Craciun 2011-05-13: >> > ? ? Lately I've started programming a bit more seriously in Erlang, >> > and after creating a few `gen_server` or `gen_fsm` components, I've >> > started wondering what is the best way to handle unexpected or invalid >> > requests / messages. [...] >> > >> > ? ? I think of three possibilities: >> > ? ? * reply back with an error: >> >> Yep, this is what I do: >> >> ?handle_call(_, _, State) -> >> ? ? ?{reply, {error, bad_request}, State}. >> >> ?handle_info(_, State) -> >> ? ? ?{noreply, State}. >> >> It's similar with gen_fsm & custom processes. >> >> > ? ? Now each of these have advantages or disadvantages: >> > >> > ? ? * the first one is "polite" to the caller, letting him retry, >> > ? ? ? but could lead to hidden bugs if the caller doesn't check >> > ? ? ? the return term; >> >> It also helps forward-compatibility in presence of hot code upgrades. >> >> > ? ? Furthermore, let's say a process depends in his operation on >> > another process, should it link the dependency process, should it >> > monitor, or should it just fail on call? >> >> Depends on how tightly they're bound together. Linking them means "one >> can't live without the other even for a second", monitoring means "one >> is vaguely interested if the other is still alive" (often to clean up >> some mess when the other dies), fail on call means "ok, I need you to >> handle my request now, but generally I don't really care about you". >> >> The last option is by far the most common, the other two are employed >> tactically in cases where it matters. >> >> HTH, >> ? ? ? ?-- Jachym >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions From ngreco@REDACTED Fri May 13 22:38:47 2011 From: ngreco@REDACTED (Nahuel Greco) Date: Fri, 13 May 2011 17:38:47 -0300 Subject: [erlang-questions] funs versus code loading In-Reply-To: References: Message-ID: On Fri, May 13, 2011 at 4:05 AM, Sam Bobroff wrote: > I agree with your (and Matthias')?comments in that it should be changed in > accordance with the patch! Erlang really needs a bug tracker... this problem is very old. Saludos, Nahuel Greco. From jesper.louis.andersen@REDACTED Fri May 13 23:44:10 2011 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Fri, 13 May 2011 23:44:10 +0200 Subject: [erlang-questions] Function Declaration Syntax In-Reply-To: References: Message-ID: On Fri, May 13, 2011 at 22:23, Joe Armstrong wrote: > No good reason. Erlang evolved from Prolog and that how it was done in > Prolog > no deep thought was involved .. Interestingly, that is also the style of Haskell: len :: [a] -> Integer len [] = 0 len (x : xs) = 1 + (len xs) And also of Standard ML: fun len [] = 0 | len (x :: xs) = 1 + (len xs) .. My usual rewrite in many cases is to use a case. It almost notates as the original idea of a simplification of the syntax: len(L) -> case L of [] -> 0; [_|R] -> 1 + len(R) end. -- J. From paul.joseph.davis@REDACTED Sat May 14 01:17:58 2011 From: paul.joseph.davis@REDACTED (Paul Davis) Date: Fri, 13 May 2011 19:17:58 -0400 Subject: [erlang-questions] Dialyzer and NIF's Message-ID: Hiya, I just spent a bit of time working on integrating Dialyzer spec checks into some NIF code I've been hacking on and I was wondering if there was a cleaner way than the pattern I ended up with. Basically, I ended up creating a couple macros that would try and confuse Dialyzer into thinking that I was returning the output of the NIF but in reality returning an error that indicated the NIF module has not been loaded. It ended up like this: % Macro to only return the error but make % dialyzer think there are two return types. -define(spoof_rval1(A), case random:uniform(100) + 10 of 1 -> A; _ -> {error, {not_loaded, ?MODULE, ?LINE}} end). % Simple macro for repeated return types -define(bin, ?spoof_rval1({ok, <<>>})). % Usage of the macros with a spec. -spec open_db(dbname()) -> {ok, db()} | error(). open_db(_Name) -> ?bin. The full module code is at [1]. Basically, my question is whether this is a really bad way of doing things of if someone has found something even more elegant method for lying about return types. [1] https://github.com/davisp/erleveldb/blob/master/src/erleveldb.erl From steven.charles.davis@REDACTED Sat May 14 02:58:42 2011 From: steven.charles.davis@REDACTED (Steve Davis) Date: Fri, 13 May 2011 17:58:42 -0700 (PDT) Subject: [erlang-questions] Function Declaration Syntax In-Reply-To: References: Message-ID: <7c649304-29e8-4d93-b348-969d74f2946b@j31g2000yqe.googlegroups.com> I like it the way it is. I never questioned it. Now that it's been asked, I would guess that your suggestion if implemented would attract many complaints from new users about weird syntax. It's also harder to scan to see the full intention of the pattern matching "entry points" to the function. So I'd say -- if it works...(which it does...) there's no need to "fix" it. Particularly since the change may be less effective than the existing status here. My 2c /s From fritchie@REDACTED Sat May 14 03:50:39 2011 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Fri, 13 May 2011 20:50:39 -0500 Subject: [erlang-questions] =?utf-8?q?how_to_access_process_heap_from_outs?= =?utf-8?q?ide_the_process?= In-Reply-To: Message of "Thu, 12 May 2011 03:40:50 +0200." <15485743.41e015f9.4dcb3aa2.ad7f7@o2.pl> Message-ID: <37069.1305337839@snookles.snookles.com> dzejefkej wrote: d> hi, I need to sniff state of the process. You can't. Well, you can cheat, using erlang:process_info/2. See http://www.erlang.org/doc/man/erlang.html#process_info-2 for the docs. Perhaps the 'backtrace' option is closest to what you might be looking for? -Scott From fritchie@REDACTED Sat May 14 04:00:06 2011 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Fri, 13 May 2011 21:00:06 -0500 Subject: [erlang-questions] sunrpc module? In-Reply-To: Message of "Fri, 13 May 2011 13:13:24 +1000." <4DCCA1D4.6030300@ghostgun.com> Message-ID: <37694.1305338406@snookles.snookles.com> jm wrote: jm> Is there a module to make sun style rpc calls from erlang, eg to jm> portmapper? See the Jungerl project at http://sourceforge.net/projects/jungerl/ or perhaps https://github.com/gebi/jungerl, specifically in the lib/rpc directory. -Scott From vances@REDACTED Sat May 14 06:47:05 2011 From: vances@REDACTED (Vance Shipley) Date: Sat, 14 May 2011 10:17:05 +0530 Subject: [erlang-questions] Determine if a binary is ref-counted in port driver code In-Reply-To: References: Message-ID: <20110514044702.GI43920@aluminum-2.local> On Thu, May 12, 2011 at 09:20:42PM +0100, Tim Watson wrote: } Currently I'm using a hack-around like so: } } if (hsize->xsl_size < 64) { } data = &ev->iov[++bin_idx].iov_base[0]; } } else { } data = ev->binv[++bin_idx]->orig_bytes; } } [...] } seems to work, but I'm fairly sure it's not The Right Thing To Do (TM). You are correct in that assumption. } Any pointers to better solutions would be much appreciated. Just don't try and do what you are trying to do. When you send to the driver what comes out the other side is what the emulator felt was the sensible thing to do. You are meant to deal with it as a binary. The iolist and iovec optimizations are lost. -- -Vance From vances@REDACTED Sat May 14 07:40:50 2011 From: vances@REDACTED (Vance Shipley) Date: Sat, 14 May 2011 11:10:50 +0530 Subject: [erlang-questions] Best practices for handling invalid / unexpected messages In-Reply-To: References: <20110513195920.GA1721@hanele.lan> Message-ID: <20110514054047.GJ43920@aluminum-2.local> Ciprian, If it's an API, either public or private, I find the sensible thing to do is to have the caller fail with `badarg' just as they would do when calling a function call with the wrong arguments. Using an API module: %% @spec (Pid::pid()) -> term() %% foo(Pid) when is_pid(Pid) -> case gen_server:call(Pid, foo) of {ok, Value} -> Value; {error, Reason} -> exit(Reason) end. The callback would be: handle_call(foo, From, State) -> ... {reply, {ok, Foo}, State}; handle_call(_, From, State) -> {reply, {error, badarg}, State}. When the client calls gen_server:call/2 directly: handle_call(foo, From, State) -> ... {reply, Foo, State}; handle_call(_, {_, Pid}, State) -> {reply, exit(Pid, badarg), State}. On Fri, May 13, 2011 at 11:34:11PM +0300, Ciprian Dorin Craciun wrote: } For example it would have been nice to have a return value like } `{error, Reason, NewState}` from callbacks like `handle_call`, etc.; } which depending on the running environment either "dispatches" } `{reply, {error, Reason}, NewState}`, or `{stop, {error, Reason}, } NewState}`. But as such a solution doesn't exist I could just create } three generic functions like `handle_call_error (Reason, NewState)` } that is called from within `handle_call` in a tail position, thus } achieving the same outcome. } } Any other ideas? -- -Vance From nox@REDACTED Sat May 14 09:35:20 2011 From: nox@REDACTED (Anthony Ramine) Date: Sat, 14 May 2011 09:35:20 +0200 Subject: [erlang-questions] Dialyzer and NIF's In-Reply-To: References: Message-ID: You should probably use erlang:nif_error/{1,2}. http://www.erlang.org/doc/man/erlang.html#nif_error-1 Le 14 mai 2011 ? 01:17, Paul Davis a ?crit : > Hiya, > > I just spent a bit of time working on integrating Dialyzer spec checks > into some NIF code I've been hacking on and I was wondering if there > was a cleaner way than the pattern I ended up with. > > Basically, I ended up creating a couple macros that would try and > confuse Dialyzer into thinking that I was returning the output of the > NIF but in reality returning an error that indicated the NIF module > has not been loaded. It ended up like this: > > % Macro to only return the error but make > % dialyzer think there are two return types. > -define(spoof_rval1(A), case random:uniform(100) + 10 of > 1 -> A; _ -> {error, {not_loaded, ?MODULE, ?LINE}} > end). > > % Simple macro for repeated return types > -define(bin, ?spoof_rval1({ok, <<>>})). > > % Usage of the macros with a spec. > -spec open_db(dbname()) -> {ok, db()} | error(). > open_db(_Name) -> ?bin. > > The full module code is at [1]. > > Basically, my question is whether this is a really bad way of doing > things of if someone has found something even more elegant method for > lying about return types. > > > [1] https://github.com/davisp/erleveldb/blob/master/src/erleveldb.erl > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Anthony Ramine Dev:Extend http://dev-extend.eu From jamie@REDACTED Sat May 14 10:58:38 2011 From: jamie@REDACTED (Jamie Brandon) Date: Sat, 14 May 2011 16:58:38 +0800 Subject: [erlang-questions] error_logger and rpc Message-ID: I encountered some confusing interactions between error_logger and rpc. My understanding is that rpc:call/4 executes the function on the remote node and any side effects happen on the remote node. However I'm finding that logs are only being handled on the local node eg jamie@REDACTED:~/retex$ erl -sname A Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:4:4] [rq:4] [async-threads:0] [kernel-poll:false] Eshell V5.8.3 (abort with ^G) (A@REDACTED)1> rpc:call('B@REDACTED', error_logger, info_report, [[test]]). =INFO REPORT==== 14-May-2011::16:50:11 === test ** at node B@REDACTED ** ok In this example nothing is shown on node B. In my case node B is a server which logs reports to disk and A is a short-lived control script ( https://github.com/jamii/retex/blob/master/control ) so these logs are being lost. I can't find this behavior documented anywhere. Can somebody explain it? Thanks Jamie From max.lapshin@REDACTED Sat May 14 11:52:19 2011 From: max.lapshin@REDACTED (Max Lapshin) Date: Sat, 14 May 2011 13:52:19 +0400 Subject: [erlang-questions] Best practices for handling invalid / unexpected messages In-Reply-To: <20110514054047.GJ43920@aluminum-2.local> References: <20110513195920.GA1721@hanele.lan> <20110514054047.GJ43920@aluminum-2.local> Message-ID: I always make handle_call(Call, _From, State) -> {stop, {invalid_call, Call}, State}. as a last clause because it is a best way to know that _I_ haven't validated call in function, that make gen_server:call From freza@REDACTED Sat May 14 12:10:14 2011 From: freza@REDACTED (Jachym Holecek) Date: Sat, 14 May 2011 11:10:14 +0100 Subject: [erlang-questions] Best practices for handling invalid / unexpected messages In-Reply-To: References: <20110513195920.GA1721@hanele.lan> Message-ID: <20110514101014.GA445@hanele.lan> # Ciprian Dorin Craciun 2011-05-13: > On Fri, May 13, 2011 at 22:59, Jachym Holecek wrote: > > Yep, this is what I do: > > [...] > > ?handle_info(_, State) -> > > ? ? ?{noreply, State}. > > > > It's similar with gen_fsm & custom processes. > > The main problem here is that it silently can "swallow" > miscommunication bugs. Yeah, but to be honest these don't really happen very often, so personally I don't bother being defensive about them. If it became a big deal, I'd probably just log unexpected messages in the catch-all branch. > > Depends on how tightly they're bound together. Linking them means "one > > can't live without the other even for a second", monitoring means "one > > is vaguely interested if the other is still alive" (often to clean up > > some mess when the other dies), fail on call means "ok, I need you to > > handle my request now, but generally I don't really care about you". > > > > The last option is by far the most common, the other two are employed > > tactically in cases where it matters. > > Indeed I'm speaking about an asymmetric relation; in general I'm > speaking about a server and it's clients, the server can live if one > client crashes, but none of the clients can without the server. > > My problem is monitoring vs linking. Linking seems more > "bullet-proof" than "monitoring"... I will guess and say the problem you're pondering (fault propagation and isolation) would be best solved at the level of supervision hierarchy design instead of doing it manually. But in general there's simply no silver bullet, ever (that's why I'm not very keen on "best practices" and "design pattern" books) -- if you have a reasonably minimal example application handy that demonstrates your dilemma then we can discuss it in more detail. ;-) BR, -- Jachym From torben.lehoff@REDACTED Sat May 14 13:34:11 2011 From: torben.lehoff@REDACTED (Torben Hoffmann) Date: Sat, 14 May 2011 13:34:11 +0200 Subject: [erlang-questions] Function Declaration Syntax In-Reply-To: References: Message-ID: On Fri, May 13, 2011 at 23:44, Jesper Louis Andersen < jesper.louis.andersen@REDACTED> wrote: > On Fri, May 13, 2011 at 22:23, Joe Armstrong wrote: > > No good reason. Erlang evolved from Prolog and that how it was done in > > Prolog > > no deep thought was involved .. > > Interestingly, that is also the style of Haskell: > > len :: [a] -> Integer > len [] = 0 > len (x : xs) = 1 + (len xs) > > And also of Standard ML: > > fun len [] = 0 > | len (x :: xs) = 1 + (len xs) > > .. > > My usual rewrite in many cases is to use a case. It almost notates as > the original idea of a simplification of the syntax: > > len(L) -> > case L of > [] -> 0; > [_|R] -> 1 + len(R) > end. > This is - in my book - a step backwards. You should haev the spec for the function and then pattern matching in the function clauses since it gives you: 1. Overview of what the function does. 2. 1st level overview of how the function branches out. This makes debugging so much faster than having to get inside a function only to meet a case on the parameters as the first thing. Cheers, Torben > > > -- > J. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- http://www.linkedin.com/in/torbenhoffmann -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebegumisa@REDACTED Sat May 14 14:52:12 2011 From: ebegumisa@REDACTED (Edmond Begumisa) Date: Sat, 14 May 2011 22:52:12 +1000 Subject: [erlang-questions] Best practices for handling invalid / unexpected messages In-Reply-To: References: <20110513195920.GA1721@hanele.lan> Message-ID: On a related note, I've now and then wondered about a UBF-style contract checker for gen_server and gen_fsm messages. I realise pattern matching is kind of implied contract checking (invalid messages don't get matched), but I like the UBF idea of starting with a contract then coding the modules from there rather than the other way around. The type-checking is also very useful. Any thoughts? - Edmond - On Sat, 14 May 2011 06:20:42 +1000, Joe Armstrong wrote: > No easy answer: > > During development: > > Crash loudly - print lots of information about why you crashed > do init:stop() or erlang:halt() *force* the programmer to fix the > code > > During production > > Crash silently - put lots of error in the log and send rude email to > programmer > if you can recover do so. If you cannot recover tell the user as > politely as possible. > *never* present the user with internal error message (this is most > unprofessional) > > What you do with an error thus depends upon the context where it occurs - > basically > tell the programmer the truth and give them all the info needed to fix > the > error, while > apologizing to the end user ... send an email to the project manager > telling > the code > is broken if you want the programmer to fix it :-) > > /Joe > > > > On Fri, May 13, 2011 at 9:59 PM, Jachym Holecek > wrote: > >> # Ciprian Dorin Craciun 2011-05-13: >> > Lately I've started programming a bit more seriously in Erlang, >> > and after creating a few `gen_server` or `gen_fsm` components, I've >> > started wondering what is the best way to handle unexpected or invalid >> > requests / messages. [...] >> > >> > I think of three possibilities: >> > * reply back with an error: >> >> Yep, this is what I do: >> >> handle_call(_, _, State) -> >> {reply, {error, bad_request}, State}. >> >> handle_info(_, State) -> >> {noreply, State}. >> >> It's similar with gen_fsm & custom processes. >> >> > Now each of these have advantages or disadvantages: >> > >> > * the first one is "polite" to the caller, letting him retry, >> > but could lead to hidden bugs if the caller doesn't check >> > the return term; >> >> It also helps forward-compatibility in presence of hot code upgrades. >> >> > Furthermore, let's say a process depends in his operation on >> > another process, should it link the dependency process, should it >> > monitor, or should it just fail on call? >> >> Depends on how tightly they're bound together. Linking them means "one >> can't live without the other even for a second", monitoring means "one >> is vaguely interested if the other is still alive" (often to clean up >> some mess when the other dies), fail on call means "ok, I need you to >> handle my request now, but generally I don't really care about you". >> >> The last option is by far the most common, the other two are employed >> tactically in cases where it matters. >> >> HTH, >> -- Jachym >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From ebegumisa@REDACTED Sat May 14 15:21:02 2011 From: ebegumisa@REDACTED (Edmond Begumisa) Date: Sat, 14 May 2011 23:21:02 +1000 Subject: [erlang-questions] Best practices for handling invalid / unexpected messages In-Reply-To: References: <20110513195920.GA1721@hanele.lan> Message-ID: To clarify, I'm referring to a contract checker for ordinary Erlang terms passed within the same VM instance and not TCP/port communication as is currently with UBF. - Edmond - On Sat, 14 May 2011 22:52:12 +1000, Edmond Begumisa wrote: > On a related note, > > I've now and then wondered about a UBF-style contract checker for > gen_server and gen_fsm messages. I realise pattern matching is kind of > implied contract checking (invalid messages don't get matched), but I > like the UBF idea of starting with a contract then coding the modules > from there rather than the other way around. The type-checking is also > very useful. > > Any thoughts? > > - Edmond - > > On Sat, 14 May 2011 06:20:42 +1000, Joe Armstrong > wrote: > >> No easy answer: >> >> During development: >> >> Crash loudly - print lots of information about why you crashed >> do init:stop() or erlang:halt() *force* the programmer to fix the >> code >> >> During production >> >> Crash silently - put lots of error in the log and send rude email to >> programmer >> if you can recover do so. If you cannot recover tell the user as >> politely as possible. >> *never* present the user with internal error message (this is most >> unprofessional) >> >> What you do with an error thus depends upon the context where it occurs >> - >> basically >> tell the programmer the truth and give them all the info needed to fix >> the >> error, while >> apologizing to the end user ... send an email to the project manager >> telling >> the code >> is broken if you want the programmer to fix it :-) >> >> /Joe >> >> >> >> On Fri, May 13, 2011 at 9:59 PM, Jachym Holecek >> wrote: >> >>> # Ciprian Dorin Craciun 2011-05-13: >>> > Lately I've started programming a bit more seriously in Erlang, >>> > and after creating a few `gen_server` or `gen_fsm` components, I've >>> > started wondering what is the best way to handle unexpected or >>> invalid >>> > requests / messages. [...] >>> > >>> > I think of three possibilities: >>> > * reply back with an error: >>> >>> Yep, this is what I do: >>> >>> handle_call(_, _, State) -> >>> {reply, {error, bad_request}, State}. >>> >>> handle_info(_, State) -> >>> {noreply, State}. >>> >>> It's similar with gen_fsm & custom processes. >>> >>> > Now each of these have advantages or disadvantages: >>> > >>> > * the first one is "polite" to the caller, letting him retry, >>> > but could lead to hidden bugs if the caller doesn't check >>> > the return term; >>> >>> It also helps forward-compatibility in presence of hot code upgrades. >>> >>> > Furthermore, let's say a process depends in his operation on >>> > another process, should it link the dependency process, should it >>> > monitor, or should it just fail on call? >>> >>> Depends on how tightly they're bound together. Linking them means "one >>> can't live without the other even for a second", monitoring means "one >>> is vaguely interested if the other is still alive" (often to clean up >>> some mess when the other dies), fail on call means "ok, I need you to >>> handle my request now, but generally I don't really care about you". >>> >>> The last option is by far the most common, the other two are employed >>> tactically in cases where it matters. >>> >>> HTH, >>> -- Jachym >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> > > -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From paul.joseph.davis@REDACTED Sat May 14 17:13:35 2011 From: paul.joseph.davis@REDACTED (Paul Davis) Date: Sat, 14 May 2011 11:13:35 -0400 Subject: [erlang-questions] Dialyzer and NIF's In-Reply-To: References: Message-ID: Anthony, Excellent! That's exactly what I needed. Paul On Sat, May 14, 2011 at 3:35 AM, Anthony Ramine wrote: > You should probably use erlang:nif_error/{1,2}. > http://www.erlang.org/doc/man/erlang.html#nif_error-1 > > Le 14 mai 2011 ? 01:17, Paul Davis a ?crit : > >> Hiya, >> >> I just spent a bit of time working on integrating Dialyzer spec checks >> into some NIF code I've been hacking on and I was wondering if there >> was a cleaner way than the pattern I ended up with. >> >> Basically, I ended up creating a couple macros that would try and >> confuse Dialyzer into thinking that I was returning the output of the >> NIF but in reality returning an error that indicated the NIF module >> has not been loaded. It ended up like this: >> >> % Macro to only return the error but make >> % dialyzer think there are two return types. >> -define(spoof_rval1(A), case random:uniform(100) + 10 of >> ? ?1 -> A; _ -> {error, {not_loaded, ?MODULE, ?LINE}} >> end). >> >> % Simple macro for repeated return types >> -define(bin, ?spoof_rval1({ok, <<>>})). >> >> % Usage of the macros with a spec. >> -spec open_db(dbname()) -> {ok, db()} | error(). >> open_db(_Name) -> ?bin. >> >> The full module code is at [1]. >> >> Basically, my question is whether this is a really bad way of doing >> things of if someone has found something even more elegant method for >> lying about return types. >> >> >> [1] https://github.com/davisp/erleveldb/blob/master/src/erleveldb.erl >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > -- > Anthony Ramine > Dev:Extend > http://dev-extend.eu > > > > > From robert.virding@REDACTED Sat May 14 21:05:43 2011 From: robert.virding@REDACTED (Robert Virding) Date: Sat, 14 May 2011 19:05:43 +0000 (GMT) Subject: [erlang-questions] Porting appmon/pman/debugger/tv to Wx? In-Reply-To: Message-ID: <157729368.177721305399943334.JavaMail.root@zimbra> If you implemented gs on top of wx then you would automatically get the tools ported. And get a more implementation independent interface. You could then at leisure improve the tools by having them directly run on wx. Robert ----- "Boris M?hmer" wrote: > It would be great if You would add another layer on top of wx. > Basically to abstract the actual "engine" beneath it. > > Maybe one day wx will be replaced by something like "freeglut", > "Ogre3D", or "something completely unknown yet". > Or there will be a new environment, where wx can't be build or > another > (G)UI exists, that should/must be used. > > > - boris > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From attila.r.nohl@REDACTED Sat May 14 21:18:51 2011 From: attila.r.nohl@REDACTED (Attila Rajmund Nohl) Date: Sat, 14 May 2011 21:18:51 +0200 Subject: [erlang-questions] Best practices for handling invalid / unexpected messages In-Reply-To: References: Message-ID: 2011/5/13, Ciprian Dorin Craciun : > Hello all! > > Lately I've started programming a bit more seriously in Erlang, > and after creating a few `gen_server` or `gen_fsm` components, I've > started wondering what is the best way to handle unexpected or invalid > requests / messages. (For example in `handle_call`, or `handle_info` > or state handlers.) (By invalid requests I mean those that have the > correct form (i.e. a tuple `{add, A, B}`) but invalid syntax (i.e. `A` > is an atom); by unexpected messages I mean those that fail to even > loosely match a valid pattern (i.e. `{some_unrecognized_operation, A, > B}`.) > > I think of three possibilities: > * reply back with an error: > ~~~~ > handle_call (Request, _Sender, State) -> {reply, {error, > {invalid_request, Request}}, State}. > ~~~~ > * exit with an error; > ~~~~ > handle_call (Request, _Sender, State) -> {stop, {error, > {invalid_request, Request}}, State}. > ~~~~ > * don't even create a special catch-all case and just let the > process fail with `function_clause` error; > > Now each of these have advantages or disadvantages: > * the first one is "polite" to the caller, letting him retry, but > could lead to hidden bugs if the caller doesn't check the return term; > * the second one I think fits more the Erlang philosophy of > "let-it-crash", but could lead to state loss (i.e. an ETS table); > * the last one I consider to be just rude as it doesn't give any > information on why it failed; Let's take a look at an example. The ssh_connection_handler is a gen_fsm in Erlang/OTP and it receives the usual gen_tcp tuples from the TCP connection in its handle_info clause. Only the tuples are handled, if some other message is received, the process dies with a function_clause error and the SSH connection is closed. This is an application-internal process, so it is safe to assume that no other kind of message will be received. Or not. The ssh application lets the user specify a callback function to authenticate the user. This function happens to be executed in the ssh_connection_handler process. Due to pressing deadlines the author of this callback (i.e. the user of the ssh application) chose to reuse some already existing framework with code like this: AuthPid = spawn(authfun, [User, Password, self()]), receive auth_passed -> true; auth_failed -> false after 10000 false end, stop_authfun(AuthPid), Then the authfun/3 sends back the authentication result to this process. Keen eyes probably noticed the problem - what happens, if the authfun sends back the result just after the 10 seconds timeout, but before it's stopped? It's the ssh_connection_handler that receives the message, but it's handle_info can't handle the unexpected message, so the process crashes, the SSH connection abruptly goes down (during authentication) and the end user complains. Even though the supervisors keep the SSH server running, it's still not ideal. Because the authentication was harder to fix, I've first changed the ssh_connection_handler:handle_info to just log on an unexpected message (this is what Joe advised in this thread, if I understood right) and it satisfied the end user, he doesn't care one extra message in the logs. On the other hand I'm not quite sure this is the right solution - if the ssh_connection_handler hadn't crashed, we wouldn't found this problem at all... (the end users never really check the logs and local blackbox testing is hardly useful for these kind of errors). So I think if you absolutely positively sure that you can't receive unexpected message (the pid of the process is only known to internal code and there are no callbacks executed), you can handle only the expected messages. If your users do check the logs regularly, you might be better of logging the unexpected message an keep the process alive. From silent_vendetta@REDACTED Sun May 15 02:18:06 2011 From: silent_vendetta@REDACTED (Chris Hicks) Date: Sat, 14 May 2011 17:18:06 -0700 Subject: [erlang-questions] Odd behavior when sending emails via SMTP when messages are converted to/from binaries In-Reply-To: References: , Message-ID: In the system I'm building I am working with all my strings as binaries. I'm doing this because I'll be deploying on a 64 bit platform and don't need all the text I'm working with blowing up in size when there isn't any need for it. However I'm noticing an odd behavior when constructing emails to send over SMTP. Basically what I'm doing is this:...Message_body = "This is a message body", <-- This part is actually more complex in that variables are being used along with string literals to form the entire body, which is why I initially create it as a string. Binary_message = erlang:term_to_binary(Message_body), email:send(Binary_message). The other module then does this:...Header = "From: xxx \rTo: yyy\rSubject: This is the subject\r", Full_message = Header ++ erlang:binary_to_list(Binary_message), send_email(Full_message). Now the message sends just fine and shows up in my email. However in front of the Message_body text are three extra characters "?k?" and if I change the second module to this:...Header = "From: xxx \rTo: yyy\rSubject: This is the subject\r",Body = erlang:binary_to_list(Binary_message), Full_message = Header ++ Body,send_email(Full_message). Then the three characters change to these"?k?" and I simply can't figure out what is going on. Now I'm not building a mail server and I don't expect to be sending thousands of emails so working around this by simply treating all email text as strings (not converting to/from binary) is certainly not a problem. I am just curious if anyone can explain or help me figure out what is going on. Chris Hicks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From silent_vendetta@REDACTED Sun May 15 04:19:51 2011 From: silent_vendetta@REDACTED (Chris Hicks) Date: Sat, 14 May 2011 19:19:51 -0700 Subject: [erlang-questions] Odd behavior when sending emails via SMTP when messages are converted to/from binaries In-Reply-To: References: , , , Message-ID: With some additional testing finally figured it out. I'm not sure how I missed it before, hard to keep track of all the tests you run after a while, but using term_to_binary then binary_to_list ends up leaving 4 extra elements in the list prior to the text which was first turned into a binary in the first place. Chris Hicks. From: silent_vendetta@REDACTED To: erlang-questions@REDACTED Date: Sat, 14 May 2011 17:18:06 -0700 Subject: [erlang-questions] Odd behavior when sending emails via SMTP when messages are converted to/from binaries In the system I'm building I am working with all my strings as binaries. I'm doing this because I'll be deploying on a 64 bit platform and don't need all the text I'm working with blowing up in size when there isn't any need for it. However I'm noticing an odd behavior when constructing emails to send over SMTP. Basically what I'm doing is this:...Message_body = "This is a message body", <-- This part is actually more complex in that variables are being used along with string literals to form the entire body, which is why I initially create it as a string. Binary_message = erlang:term_to_binary(Message_body), email:send(Binary_message). The other module then does this:...Header = "From: xxx \rTo: yyy\rSubject: This is the subject\r", Full_message = Header ++ erlang:binary_to_list(Binary_message), send_email(Full_message). Now the message sends just fine and shows up in my email. However in front of the Message_body text are three extra characters "?k?" and if I change the second module to this:...Header = "From: xxx \rTo: yyy\rSubject: This is the subject\r",Body = erlang:binary_to_list(Binary_message), Full_message = Header ++ Body,send_email(Full_message). Then the three characters change to these"?k?" and I simply can't figure out what is going on. Now I'm not building a mail server and I don't expect to be sending thousands of emails so working around this by simply treating all email text as strings (not converting to/from binary) is certainly not a problem. I am just curious if anyone can explain or help me figure out what is going on. Chris Hicks. _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From juanjo@REDACTED Sun May 15 04:28:12 2011 From: juanjo@REDACTED (Juan Jose Comellas) Date: Sat, 14 May 2011 23:28:12 -0300 Subject: [erlang-questions] Odd behavior when sending emails via SMTP when messages are converted to/from binaries In-Reply-To: References: Message-ID: Yes, the correct thing to do would be to use list_to_binary/1 and binary_to_list/1. It might be possible to avoid the conversion altogether if you're writing the result of the conversion to a socket or a file. If so, you could just build an iolist and parse what you receive directly as a binary. Juanjo On Sat, May 14, 2011 at 11:19 PM, Chris Hicks wrote: > With some additional testing finally figured it out. I'm not sure how I > missed it before, hard to keep track of all the tests you run after a while, > but using term_to_binary then binary_to_list ends up leaving 4 extra > elements in the list prior to the text which was first turned into a binary > in the first place. > Chris Hicks. > > ________________________________ > From: silent_vendetta@REDACTED > To: erlang-questions@REDACTED > Date: Sat, 14 May 2011 17:18:06 -0700 > Subject: [erlang-questions] Odd behavior when sending emails via SMTP when > messages are converted to/from binaries > > In the system I'm building I am working with all my strings as binaries. I'm > doing this because I'll be deploying on a 64 bit platform and don't need all > the text I'm working with blowing up in size when there isn't any need for > it. However I'm noticing an odd behavior when constructing emails to send > over SMTP. > Basically what I'm doing is this: > ... > Message_body = "This is a message body", <-- This part is actually more > complex in that variables are being used along with string literals to form > the entire body, which is why I initially create it as a string. > Binary_message = erlang:term_to_binary(Message_body), > email:send(Binary_message). > > The other module then does this: > ... > Header = "From: xxx \rTo: yyy\rSubject: This is the subject\r", > Full_message = Header ++ erlang:binary_to_list(Binary_message), > send_email(Full_message). > > Now the message sends just fine and shows up in my email. However in front > of the Message_body text are three extra characters "?k ?" and if I change > the second module to this: > ... > Header = "From: xxx \rTo: yyy\rSubject: This is the subject\r", > Body = erlang:binary_to_list(Binary_message), > Full_message = Header ++ Body, > send_email(Full_message). > > Then the three characters change to these"?k ?" and I simply can't figure > out what is going on. Now I'm not building a mail server and I don't expect > to be sending thousands of emails so working around this by simply treating > all email text as strings (not converting to/from binary) is certainly not a > problem. I am just curious if anyone can explain or help me figure out what > is going on. > Chris Hicks. > > _______________________________________________ erlang-questions mailing > list erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > From silent_vendetta@REDACTED Sun May 15 04:34:52 2011 From: silent_vendetta@REDACTED (Chris Hicks) Date: Sat, 14 May 2011 19:34:52 -0700 Subject: [erlang-questions] Odd behavior when sending emails via SMTP when messages are converted to/from binaries In-Reply-To: References: , , , , Message-ID: I honestly don't know why I thought that there wasn't a list_to_binary function...I suppose thats what you get for programming late into the night. I believe it was on How I Met Your Mother that I heard the phrase "Nothing good ever happens after 2am." I should probably take that to heart when it comes to coding. > Date: Sat, 14 May 2011 23:28:12 -0300 > Subject: Re: [erlang-questions] Odd behavior when sending emails via SMTP when messages are converted to/from binaries > From: juanjo@REDACTED > To: silent_vendetta@REDACTED > CC: erlang-questions@REDACTED > > Yes, the correct thing to do would be to use list_to_binary/1 and > binary_to_list/1. > > It might be possible to avoid the conversion altogether if you're > writing the result of the conversion to a socket or a file. If so, you > could just build an iolist and parse what you receive directly as a > binary. > > Juanjo > > > On Sat, May 14, 2011 at 11:19 PM, Chris Hicks > wrote: > > With some additional testing finally figured it out. I'm not sure how I > > missed it before, hard to keep track of all the tests you run after a while, > > but using term_to_binary then binary_to_list ends up leaving 4 extra > > elements in the list prior to the text which was first turned into a binary > > in the first place. > > Chris Hicks. > > > > ________________________________ > > From: silent_vendetta@REDACTED > > To: erlang-questions@REDACTED > > Date: Sat, 14 May 2011 17:18:06 -0700 > > Subject: [erlang-questions] Odd behavior when sending emails via SMTP when > > messages are converted to/from binaries > > > > In the system I'm building I am working with all my strings as binaries. I'm > > doing this because I'll be deploying on a 64 bit platform and don't need all > > the text I'm working with blowing up in size when there isn't any need for > > it. However I'm noticing an odd behavior when constructing emails to send > > over SMTP. > > Basically what I'm doing is this: > > ... > > Message_body = "This is a message body", <-- This part is actually more > > complex in that variables are being used along with string literals to form > > the entire body, which is why I initially create it as a string. > > Binary_message = erlang:term_to_binary(Message_body), > > email:send(Binary_message). > > > > The other module then does this: > > ... > > Header = "From: xxx \rTo: yyy\rSubject: This is the subject\r", > > Full_message = Header ++ erlang:binary_to_list(Binary_message), > > send_email(Full_message). > > > > Now the message sends just fine and shows up in my email. However in front > > of the Message_body text are three extra characters "?k ?" and if I change > > the second module to this: > > ... > > Header = "From: xxx \rTo: yyy\rSubject: This is the subject\r", > > Body = erlang:binary_to_list(Binary_message), > > Full_message = Header ++ Body, > > send_email(Full_message). > > > > Then the three characters change to these"?k ?" and I simply can't figure > > out what is going on. Now I'm not building a mail server and I don't expect > > to be sending thousands of emails so working around this by simply treating > > all email text as strings (not converting to/from binary) is certainly not a > > problem. I am just curious if anyone can explain or help me figure out what > > is going on. > > Chris Hicks. > > > > _______________________________________________ erlang-questions mailing > > list erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cognition.mind@REDACTED Sun May 15 06:03:01 2011 From: cognition.mind@REDACTED (cognition.mind) Date: Sat, 14 May 2011 21:03:01 -0700 (PDT) Subject: [erlang-questions] Erlangers in Montreal? In-Reply-To: <4D83B9A3.9050801@gmail.com> References: <4D83B9A3.9050801@gmail.com> Message-ID: <1305432181256-3523815.post@n4.nabble.com> I live in Gatineau, but sounds like an idea, I just started learning erlang and have come to really love it, Keep me posted if anything gets moving. Cheers Ramon ----- Empires fall. Religions dissolve like mist. But quotes about monkeys with keyboards live for eternity. - The Covert Comic -- View this message in context: http://erlang.2086793.n4.nabble.com/Erlangers-in-Montreal-tp3388272p3523815.html Sent from the Erlang Questions mailing list archive at Nabble.com. From ulf.wiger@REDACTED Sun May 15 07:25:03 2011 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Sun, 15 May 2011 07:25:03 +0200 Subject: [erlang-questions] Best practices for handling invalid / unexpected messages In-Reply-To: References: <20110513195920.GA1721@hanele.lan> Message-ID: <0A72EA6C-D7F1-4300-8E6D-57D1E589D481@erlang-solutions.com> On 13 May 2011, at 22:24, Ciprian Dorin Craciun wrote: > My problem is monitoring vs linking. Linking seems more > "bullet-proof" than "monitoring"? No, monitors and links are just *different*, and complementary. The great value of links - their intended use, original impetus and default mode - is cascading exits. If a process dies, all processes linked to it will also die. As Bjarne D?cker has told, this idea came from the old telephone switches where grounding the 'C' line would release all resources held by a call, through a cascade of relays. There was another mode needed, where a process reached by an exit notification was not terminated, but instead could react. The initial solution was to modify the behaviour of EXIT signal reception through the process flag 'trap_exit'. But as is often the case when overloading a behaviour, the solution was flawed: - you can call link(P) as many times as you want, but you will only have at most one link to process P - if you call unlink(P) even once, the link to P will be removed - this meant that link/1 was impractical for temporary supervision, a la gen_server:call/2 (A potential problem in the old days was that if a child unlinked from its supervisor, this could subvert the shutdown protocol and make shutdown hang. Nowadays, supervisors use both links and monitors?) So monitors were included to make it possible to react instantly to the death of a process, if it happens to die *as I am interacting with it*, but ignore it otherwise. As it happens, monitors are also great for monitoring processes. Links remain great for their original purpose - cascading exits. BR, Ulf W Ulf Wiger, CTO, Erlang Solutions, Ltd. http://erlang-solutions.com From mjtruog@REDACTED Sun May 15 10:30:17 2011 From: mjtruog@REDACTED (Michael Truog) Date: Sun, 15 May 2011 01:30:17 -0700 Subject: [erlang-questions] [ANN] CloudI 0.1.6 Released Message-ID: <4DCF8F19.30506@gmail.com> Changes in this release include: * build/installation system fixes * FAQ information release (http://cloudi.org/faq.html) CloudI is still being kept as alpha (for now) while more testing and documentation takes place. 0.2.0 will be the beta release. Download from http://sourceforge.net/projects/cloudi/files/0.1.6a/cloudi-0.1.6.tar.gz/download Anyone with questions, comments, ideas, suggestions, criticisms, or concerns is welcome to send email. Thanks, Michael From nox@REDACTED Sun May 15 13:41:23 2011 From: nox@REDACTED (Anthony Ramine) Date: Sun, 15 May 2011 13:41:23 +0200 Subject: [erlang-questions] Porting appmon/pman/debugger/tv to Wx? In-Reply-To: <157729368.177721305399943334.JavaMail.root@zimbra> References: <157729368.177721305399943334.JavaMail.root@zimbra> Message-ID: wx is already a GUI abstraction toolkit; I don't think putting an abstraction on top of an abstraction is the way to go here. Le 14 mai 2011 ? 21:05, Robert Virding a ?crit : > If you implemented gs on top of wx then you would automatically get the tools ported. And get a more implementation independent interface. You could then at leisure improve the tools by having them directly run on wx. > > Robert > > ----- "Boris M?hmer" wrote: > >> It would be great if You would add another layer on top of wx. >> Basically to abstract the actual "engine" beneath it. >> >> Maybe one day wx will be replaced by something like "freeglut", >> "Ogre3D", or "something completely unknown yet". >> Or there will be a new environment, where wx can't be build or >> another >> (G)UI exists, that should/must be used. >> >> >> - boris >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Anthony Ramine Dev:Extend http://dev-extend.eu From dan@REDACTED Sun May 15 17:36:32 2011 From: dan@REDACTED (Daniel Dormont) Date: Sun, 15 May 2011 11:36:32 -0400 Subject: [erlang-questions] Best practices for handling invalid / unexpected messages In-Reply-To: References: <20110513195920.GA1721@hanele.lan> <20110514054047.GJ43920@aluminum-2.local> Message-ID: On May 14, 2011, at 5:52 AM, Max Lapshin wrote: > I always make > > handle_call(Call, _From, State) -> > {stop, {invalid_call, Call}, State}. > > as a last clause because it is a best way to know that _I_ haven't > validated call in function, that make gen_server:call Is this in a scenario where you're using an API? I think this is an area where I'm still confused about the Erlang design approach. Perhaps naively, I'd think that killing the entire gen_server process and losing its State is a pretty drastic response to an invalid call. I guess the real question is what's detecting the crash and what are they doing about it? dan From max.lapshin@REDACTED Sun May 15 19:03:12 2011 From: max.lapshin@REDACTED (Max Lapshin) Date: Sun, 15 May 2011 21:03:12 +0400 Subject: [erlang-questions] Best practices for handling invalid / unexpected messages In-Reply-To: References: <20110513195920.GA1721@hanele.lan> <20110514054047.GJ43920@aluminum-2.local> Message-ID: On Sun, May 15, 2011 at 7:36 PM, Daniel Dormont wrote: > > On May 14, 2011, at 5:52 AM, Max Lapshin wrote: > >> I always make >> >> handle_call(Call, _From, State) -> >> ?{stop, {invalid_call, Call}, State}. >> >> as a last clause because it is a best way to know that _I_ haven't >> validated call in function, that make gen_server:call > > Is this in a scenario where you're using an API? I think this is an area where I'm still confused about the Erlang design approach. Perhaps naively, I'd think that killing the entire gen_server process and losing its State is a pretty drastic response to an invalid call. I guess the real question is what's detecting the crash and what are they doing about it? It _is_ a good idea to loose state, because your module should be designed so: -module(rtmp_session). -export([make_funcall/2]). make_funcall(RTMPSession, RTMPFuncall) when is_pid(RTMPSession) -> is_valid_funcall(RTMPFuncall) orelse erlang:error(invalid_funcall), gen_server:call(RTMPSession, {make_funcall, RTMPFuncall}). .... handle_call({make_funcall, ... You should never expose that your process is gen_server to the outside, because you may move some functionality from inside gen_server to the caller process. So it is a good idea to make all checks in caller process before gen_server:call. That is why wrong handle_call clause is a wrong design of your calling chain and your gen_server cannot handle it anymore. So, it means, that your module have passed invalid call inside its gen_server process. You can't and you should not handle this error, because it is a design error, not runtime. If you silently throws away any messages and calls, you will have raising amount of probems in your code. From bob@REDACTED Sun May 15 21:32:00 2011 From: bob@REDACTED (Bob Cowdery) Date: Sun, 15 May 2011 20:32:00 +0100 Subject: [erlang-questions] Multiple wx-erlang processes Message-ID: <4DD02A30.6010704@bobcowdery.plus.com> Hi, This seems to initialise ok but is it the correct way to do things before I start implementing the main functions. I have a main wx processing using wx_object behaviour. This handles all the user interaction stuff. Now I want a separate process that will handle graphic displays. I create another wx_object process and start it from the main wx process The start/2 and init/2 of the graphic display. start(Env, Frame) -> wx_object:start_link({local, ?MODULE}, ?MODULE, [Env, Frame], []), {ok, self()}. init([Env, Frame]) -> io:format("~p starting~n", [?MODULE]), wx:set_env(Env), {Frame, #state{}}. I pass in wx:get_env() and the main frame of the main wx process as I don't want another frame. Then call from the main process (which is using AUI) to set up the drawing surface. handle_cast({create_display, Parent, Manager, Pane}, State) -> %% Canvas on which to build graphics Canvas = wxPanel:new(Parent, [{style, ?wxFULL_REPAINT_ON_RESIZE}]), ... Regards Bob From hynek@REDACTED Sun May 15 22:16:05 2011 From: hynek@REDACTED (Hynek Vychodil) Date: Sun, 15 May 2011 22:16:05 +0200 Subject: [erlang-questions] opaque type definition makes dialyzer unhappy even in same module Message-ID: Hi, I'm playing with dialyzer in mine attempt to fibonacci heap implementation and I got weird behavior. When I define fib_heap() as type dialyzer seems happy but when I change it to -opaque it produce warnings below $ dialyzer fib_heap.erl Checking whether the PLT /home/hynek/.dialyzer_plt is up-to-date... yes Proceeding with analysis... fib_heap.erl:32: The call fib_heap:reset_min_(H::[any()]) does not have an opaque term of type fib_heap:fib_heap() as 1st argument fib_heap.erl:46: The call fib_heap:reset_min_(T::[any()],H::any(),[]) does not have opaque terms as 1st and 3rd arguments fib_heap.erl:53: The call fib_heap:reset_min_(T::[any()],H::{_,_},[any(),...]) does not have opaque terms as 1st and 3rd arguments fib_heap.erl:55: The call fib_heap:reset_min_(T::[any()],Min::any(),[any(),...]) does not have opaque terms as 1st and 3rd arguments fib_heap.erl:64: The call fib_heap:compact_(nonempty_maybe_improper_list(),array()) does not have an opaque term of type fib_heap:fib_heap() as 1st argument done in 0m0.72s done (warnings were emitted) What is going on? According to documentation: "Types declared as opaque represent sets of terms whose structure is not supposed to be visible in any way outside of their defining module (i.e., only the module defining them is allowed to depend on their term structure)." I only changed '-type' to '-opaque' on line 8, I stay in same module but dialyzer emits warnings which I don't understand and don't know how I should fix or suppress. -- --Hynek (Pichi) Vychodil -------------- next part -------------- A non-text attachment was scrubbed... Name: fib_heap.erl Type: text/x-erlang Size: 2005 bytes Desc: not available URL: From steven.charles.davis@REDACTED Sun May 15 22:37:12 2011 From: steven.charles.davis@REDACTED (Steve Davis) Date: Sun, 15 May 2011 13:37:12 -0700 (PDT) Subject: [erlang-questions] Porting appmon/pman/debugger/tv to Wx? In-Reply-To: References: <20110513042410.GE43920@aluminum-2.local> Message-ID: <98f1813a-839e-4ed5-8192-8234dd22a9a7@28g2000yqu.googlegroups.com> I looked at the feasibility of doing that. Below is a link to the open sourced "experiment". Note that this codebase has come a fair distance since the time of those initial drops, having driven down to largely talking to the wx port, and leaving the current, rather thin, and very non-standard erlang API out of the picture. When I consider this alternative API valid for general use, I'll do a big drop with an Apache 2 license. Until that time, however, I am not committing to any timescale. https://github.com/komone/gx /s On May 13, 2:02?am, Boris M?hmer wrote: > It would be great if You would add another layer on top of wx. > Basically to abstract the actual "engine" beneath it. > > Maybe one day wx will be replaced by something like "freeglut", > "Ogre3D", or "something completely unknown yet". > Or there will be a new environment, where wx can't be build or another > (G)UI exists, that should/must be used. > > ? - boris > _______________________________________________ > erlang-questions mailing list > erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions From jeffm@REDACTED Mon May 16 01:24:13 2011 From: jeffm@REDACTED (jm) Date: Mon, 16 May 2011 09:24:13 +1000 Subject: [erlang-questions] sunrpc module? In-Reply-To: <37694.1305338406@snookles.snookles.com> References: <37694.1305338406@snookles.snookles.com> Message-ID: <4DD0609D.1080603@ghostgun.com> Thanks. I'd looked through the Erlang doc and did a few web searches, but couldn't find anything. Jeff. On 14/05/11 12:00 PM, Scott Lystig Fritchie wrote: > jm wrote: > > jm> Is there a module to make sun style rpc calls from erlang, eg to > jm> portmapper? > > See the Jungerl project at http://sourceforge.net/projects/jungerl/ or > perhaps https://github.com/gebi/jungerl, specifically in the lib/rpc > directory. > > -Scott From andrew@REDACTED Mon May 16 03:41:04 2011 From: andrew@REDACTED (Andrew Thompson) Date: Sun, 15 May 2011 21:41:04 -0400 Subject: [erlang-questions] Odd behavior when sending emails via SMTP when messages are converted to/from binaries In-Reply-To: References: Message-ID: <20110516014104.GA11203@hijacked.us> On Sat, May 14, 2011 at 07:34:52PM -0700, Chris Hicks wrote: > > I honestly don't know why I thought that there wasn't a list_to_binary function...I suppose thats what you get for programming late into the night. I believe it was on How I Met Your Mother that I heard the phrase "Nothing good ever happens after 2am." I should probably take that to heart when it comes to coding. > Just out of curiosity, are you aware that libraries for constructing and sending MIME email are already present as part of the gen_smtp project? Might save you some some time and further headaches. Andrew From silent_vendetta@REDACTED Mon May 16 04:54:58 2011 From: silent_vendetta@REDACTED (Chris Hicks) Date: Sun, 15 May 2011 19:54:58 -0700 Subject: [erlang-questions] Odd behavior when sending emails via SMTP when messages are converted to/from binaries In-Reply-To: <20110516014104.GA11203@hijacked.us> References: , , , , , , <20110516014104.GA11203@hijacked.us> Message-ID: I've taken a look at that project previously and it certainly looked interesting, though that wasn't my problem. The sending of the emails has worked pretty much flawlessly the entire time. The only trouble I was having was with the extra characters appearing. I've already decided that if I end up needing more functionality than I already have that I'll probably work the gen_smtp project into what I'm doing rather than reinvent the wheel. At the moment, though, all I'm doing is sending out short emails confirming registration and things of that nature. Chris Hicks. > Date: Sun, 15 May 2011 21:41:04 -0400 > From: andrew@REDACTED > To: erlang-questions@REDACTED > Subject: Re: [erlang-questions] Odd behavior when sending emails via SMTP when messages are converted to/from binaries > > On Sat, May 14, 2011 at 07:34:52PM -0700, Chris Hicks wrote: > > > > I honestly don't know why I thought that there wasn't a list_to_binary function...I suppose thats what you get for programming late into the night. I believe it was on How I Met Your Mother that I heard the phrase "Nothing good ever happens after 2am." I should probably take that to heart when it comes to coding. > > > > Just out of curiosity, are you aware that libraries for constructing and > sending MIME email are already present as part of the gen_smtp project? > > Might save you some some time and further headaches. > > Andrew > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Mon May 16 05:06:34 2011 From: ok@REDACTED (Richard O'Keefe) Date: Mon, 16 May 2011 15:06:34 +1200 Subject: [erlang-questions] Function Declaration Syntax In-Reply-To: References: Message-ID: <7463710B-67D7-4B17-89F3-5520D19EADF7@cs.otago.ac.nz> On 13/05/2011, at 9:43 PM, Justus wrote: > Hi all, > > I come to a question on function declaration syntax: why does function > name appear in each clause? > > Name(Pattern11,...,Pattern1N) [when GuardSeq1] -> > Body1; > ...; > Name(PatternK1,...,PatternKN) [when GuardSeqK] -> > BodyK. Why not? That's how you do do it in mathematics when defining a recurrence. That's how it's done in Haskell. That's how it's done in SML. That's how it's done in every functional language I know that _has_ multiple clauses (so, not in Lisp). > > It does not provide any information, except that one might make silly mistakes. Which do you suppose human beings rely on, when reading the code, to tell whether clauses belong together? - the function name at the beginning of the line where they can see it - a distinction between "." and ";" at differently placed ends of lines? > If omitting it, a new problem is how to indent clauses properly and > beautifully. > > Name(Pattern11,...,Pattern1N) [when GuardSeq1] -> > Body1; > (PatternK1,...,PatternKN) [when GuardSeqK] -> > BodyK. Don't. Use 'case' instead. For what it's worth, I write fun (....) when ... -> ... ; (....) when ... -> ... end. If you don't have a name to make the alignment obvious, you desperately need the semicolon out the front. From ok@REDACTED Mon May 16 05:46:21 2011 From: ok@REDACTED (Richard O'Keefe) Date: Mon, 16 May 2011 15:46:21 +1200 Subject: [erlang-questions] Reltool, system crashes and ports In-Reply-To: <546897070.176471305290181612.JavaMail.root@zimbra> References: <546897070.176471305290181612.JavaMail.root@zimbra> Message-ID: <172A1EA2-50E9-4D7D-951E-FD0FDA6DF610@cs.otago.ac.nz> On 14/05/2011, at 12:36 AM, Robert Virding wrote: > P.S. The mac wouldn't let me get a core dump, irrespective of my doing "ulimit -c unlimited". Therefore I include at the end some info which it asked me if it could send to apple about the error. It might provide some help. I don't know what the Apple programmers were smoking, but (1) 'ulimit -c unlimited' does indeed enable core dumps; (2) core dumps are NOT written to the current directory or indeed to any user directory, they are written to /cores (3) You must have write permission on /cores, which you almost certainly don't. I'm typing this on a Mac. 'root' can write to /cores. Anyone in the 'admin' group can write to /cores. Me, I can't. Now it _may_ be possible to ask your friendly sysadmin to make /cores world-writable, which you probably don't really want, or better still, to use the Access Control List support in Mac OS X to give you permission to write it. (No, I don't know if this works.) Try as I might, I have been unable to see any merit in this approach. Nor was I impressed or pleased when Apple replaced the trace command that I *could* use with stuff based on DTrace, which I *can't* use. >> >> And yes wxwidgets is not as stable on mac as the other ports and it's >> not 100% system independent, >> so erlang code written on linux don't always work on mac if it is not >> tested there. >> And not everyone one of us have macs to test it with, which makes us >> rely on opensource >> contributions on platforms not used at Ericsson such as Mac OSX. This sounds like a compelling reason NOT to abandon gs and NOT to switch to wx. Ericsson can't afford ?250 for a second-hand 17" iMac to do testing on? We have labs full of Macs. Even the Linux and Windows boxes are Macs. From ok@REDACTED Mon May 16 05:58:36 2011 From: ok@REDACTED (Richard O'Keefe) Date: Mon, 16 May 2011 15:58:36 +1200 Subject: [erlang-questions] Function Declaration Syntax In-Reply-To: References: Message-ID: <3E5DD6BD-6129-4114-838C-6158CE886033@cs.otago.ac.nz> On 14/05/2011, at 3:01 AM, Attila Rajmund Nohl wrote: > The (usual) problem is that this is not consistent. You have to write > the function name for different function clauses, but must not write > the 'fun' for different clauses in anonymous functions. I would prefer > the 'fun' anu anonymous functions too. But that's because "fun" isn't the anonymous function's name. The name of the anonymous function *is* repeated in every clause. That name is the sequence of characters strictly between these brackets: []. fun (........) -> ....... ^ name ; (........) -> ....... ^ exactly the same name again end. You may not *like* the name being invisible, especially because that makes it impossible to write recursive funs, but you can't really call it inconsistent (:-) (:-). An interesting alternative would be to allow fun F(N) when is_integer(N), N > 1 -> F(N-1) + F(N-2) ; F(1) -> 1 ; F(0) -> 1 end and if the variable here were optional (either appearing in all clauses or disappearing in all clauses) it would be clear that the traditional form has a consistently repeated but invisible name. The thing that makes funs look ugly is people putting the semicolons in the wrong place... From dan@REDACTED Mon May 16 06:02:27 2011 From: dan@REDACTED (Daniel Dormont) Date: Mon, 16 May 2011 00:02:27 -0400 Subject: [erlang-questions] Function Declaration Syntax In-Reply-To: <3E5DD6BD-6129-4114-838C-6158CE886033@cs.otago.ac.nz> References: <3E5DD6BD-6129-4114-838C-6158CE886033@cs.otago.ac.nz> Message-ID: I'd like to add that neither Haskell nor Standard ML, both of which I used long before I discovered Erlang, allow anonymous functions to have multiple clauses. Discovering that feature in Erlang was a nice treat. On the other hand, they do both allow nested named (and hence recursive) functions :) dan On Sun, May 15, 2011 at 11:58 PM, Richard O'Keefe wrote: > > On 14/05/2011, at 3:01 AM, Attila Rajmund Nohl wrote: > > > The (usual) problem is that this is not consistent. You have to write > > the function name for different function clauses, but must not write > > the 'fun' for different clauses in anonymous functions. I would prefer > > the 'fun' anu anonymous functions too. > > But that's because "fun" isn't the anonymous function's name. > The name of the anonymous function *is* repeated in every clause. > That name is the sequence of characters strictly between these > brackets: []. > > fun (........) -> ....... > ^ name > ; (........) -> ....... > ^ exactly the same name again > end. > > You may not *like* the name being invisible, especially because that > makes it impossible to write recursive funs, but you can't really > call it inconsistent (:-) (:-). > > An interesting alternative would be to allow > > fun F(N) when is_integer(N), N > 1 -> F(N-1) + F(N-2) > ; F(1) -> 1 > ; F(0) -> 1 > end > > and if the variable here were optional (either appearing in all > clauses or disappearing in all clauses) it would be clear that the > traditional form has a consistently repeated but invisible name. > > The thing that makes funs look ugly is people putting the semicolons > in the wrong place... > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mapandfold@REDACTED Mon May 16 06:20:58 2011 From: mapandfold@REDACTED (Justus) Date: Mon, 16 May 2011 12:20:58 +0800 Subject: [erlang-questions] Function Declaration Syntax In-Reply-To: <7463710B-67D7-4B17-89F3-5520D19EADF7@cs.otago.ac.nz> References: <7463710B-67D7-4B17-89F3-5520D19EADF7@cs.otago.ac.nz> Message-ID: On Mon, May 16, 2011 at 11:06 AM, Richard O'Keefe wrote: > > Why not? > That's how you do do it in mathematics when defining a recurrence. > That's how it's done in Haskell. > That's how it's done in SML. > That's how it's done in every functional language I know that _has_ > multiple clauses (so, not in Lisp). That's not good reasoning. Mathematica (it's as a FP language as Lisp) also lists function names in each parameter pattern, but its semantics is quite different from Erlang: say[n_] := "n"; say[0] := "zero"; When calling say[0], the 2nd definition is used because it's more *specific* than the 1st one. -- Different from Erlang. The reason of the existence of function names here is mainly to help us/ctags, etc not to get lost in code, although Joe said no deep though is involved. That's OK, I like it. >> >> It does not provide any information, except that one might make silly mistakes. > > Which do you suppose human beings rely on, when reading the code, > to tell whether clauses belong together? > > ?- the function name at the beginning of the line where they can see it > ?- a distinction between "." and ";" at differently placed ends of lines? > >> If omitting it, a new problem is how to indent clauses properly and >> beautifully. >> >> Name(Pattern11,...,Pattern1N) [when GuardSeq1] -> >> ? ?Body1; >> ? ?(PatternK1,...,PatternKN) [when GuardSeqK] -> >> ? ?BodyK. > > Don't. ?Use 'case' instead. > > For what it's worth, I write > > ? ? ? ?fun (....) when ... -> > ? ? ? ? ? ?... > ? ? ? ? ?; (....) when ... -> > ? ? ? ? ? ?... > ? ? ? ?end. > > If you don't have a name to make the alignment obvious, you desperately > need the semicolon out the front. > > Regarding eep-0028, I think putting ";" at the beginning of a line is totally a bad idea, a big error in typesetting. There is already a symbol for alignment, "(". How about this: fun (...) when ... -> ? ?...; (...) when ... -> ? ?... end. PS, after learn something about J, one might start to dislike anything that seems to be redundant. -- Best Regards, Justus From ok@REDACTED Mon May 16 07:39:48 2011 From: ok@REDACTED (Richard O'Keefe) Date: Mon, 16 May 2011 17:39:48 +1200 Subject: [erlang-questions] Fwd: Function Declaration Syntax References: <8EC32AC8-5AD7-4028-830A-460C7B767C04@cs.otago.ac.nz> Message-ID: Begin forwarded message: > From: Richard O'Keefe > Date: 16 May 2011 5:39:11 PM NZST > To: Justus > Subject: Re: [erlang-questions] Function Declaration Syntax > > > On 16/05/2011, at 4:19 PM, Justus wrote: > >> On Mon, May 16, 2011 at 11:06 AM, Richard O'Keefe wrote: >>> >>> Why not? >>> That's how you do do it in mathematics when defining a recurrence. >>> That's how it's done in Haskell. >>> That's how it's done in SML. >>> That's how it's done in every functional language I know that _has_ >>> multiple clauses (so, not in Lisp). >> >> That's not good reasoning. > > Sure it is. It goes like this: > > (A) A certain kind of notation is widespread in a certain area. > (B) Therefore people should not be surprised to find that notation > used in that area. > >> Mathematica (it's as a FP language as Lisp) >> also lists function names in each parameter pattern, but its semantics >> is quite different from Erlang: >> >> say[n_] := "n"; >> say[0] := "zero"; > > So what? How does this make repeating the name a bad thing to do. >> >> The reason of the existence of function names here is mainly to help >> us/ctags, etc not to get lost in code, although Joe said no deep >> though is involved. That's OK, I like it. > > In fact Joe denied ctags being a reason. He just followed a tradition. >>> >>> >> >> Regarding eep-0028, I think putting ";" at the beginning of a line is >> totally a bad idea, a big error in typesetting. > > It has nothing to do with typesetting. > If only Dijkstra hadn't died, I could have told him you thought his > code layout was "totally a bad idea, a big error". > >> There is already a >> symbol for alignment, "(". > > No, that is NOT a symbol for alignment. > How can you use "(" for alignment in "if", "case", "try", > or "receive"? You can't. But you *can* use ";". > >> >> PS, after learn something about J, one might start to dislike anything >> that seems to be redundant. > > I learned J many years ago, and very quickly learned to dislike J. > > *Limited* redundancy is necessary for detecting and diagnosing errors. > From sunwood360@REDACTED Mon May 16 08:54:26 2011 From: sunwood360@REDACTED (envelopes envelopes) Date: Sun, 15 May 2011 23:54:26 -0700 Subject: [erlang-questions] Erlang based software package management system Message-ID: hi I am wondering whether there is any existing erlang based open source project that can manage C++/java software package across a cluster and also be responsible for service/stop in every machine in the cluster? for time being, I am using bash script to rsync c++/java package into all boxes. thanks! -sun -------------- next part -------------- An HTML attachment was scrubbed... URL: From dgud@REDACTED Mon May 16 09:26:47 2011 From: dgud@REDACTED (Dan Gudmundsson) Date: Mon, 16 May 2011 09:26:47 +0200 Subject: [erlang-questions] Multiple wx-erlang processes In-Reply-To: <4DD02A30.6010704@bobcowdery.plus.com> References: <4DD02A30.6010704@bobcowdery.plus.com> Message-ID: Yes that is how how handle set/get_env. But why not create the panel and setup the event subscription inside init as well, the thought here was that wx_object is used to override the C++ object and thus you return {Panel, State} from init. /Dan On Sun, May 15, 2011 at 9:32 PM, Bob Cowdery wrote: > Hi, > > This seems to initialise ok but is it the correct way to do things > before I start implementing the main functions. > > I have a main wx processing using wx_object behaviour. This handles all > the user interaction stuff. Now I want a separate process that will > handle graphic displays. I create another wx_object process and start it > from the main wx process > > The start/2 and init/2 of the graphic display. > > start(Env, Frame) -> > ? ?wx_object:start_link({local, ?MODULE}, ?MODULE, [Env, Frame], []), > ? ?{ok, self()}. > > init([Env, Frame]) -> > ? ?io:format("~p starting~n", [?MODULE]), > ? ?wx:set_env(Env), > ? ?{Frame, #state{}}. > > I pass in wx:get_env() and the main frame of the main wx process as I > don't want another frame. > > Then call from the main process (which is using AUI) to set up the > drawing surface. > > handle_cast({create_display, Parent, Manager, Pane}, State) -> > ? ?%% Canvas on which to build graphics > ? ?Canvas = wxPanel:new(Parent, [{style, ?wxFULL_REPAINT_ON_RESIZE}]), > ? ?... > > Regards > Bob > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From bob@REDACTED Mon May 16 10:02:10 2011 From: bob@REDACTED (Bob Cowdery) Date: Mon, 16 May 2011 09:02:10 +0100 Subject: [erlang-questions] Multiple wx-erlang processes In-Reply-To: References: <4DD02A30.6010704@bobcowdery.plus.com> Message-ID: <4DD0DA02.30401@bobcowdery.plus.com> Dan Thanks, good to know I'm on the right track. Bob On 16/05/2011 08:26, Dan Gudmundsson wrote: > Yes that is how how handle set/get_env. > > But why not create the panel and setup the event subscription inside > init as well, > the thought here was that wx_object is used to override the C++ object and > thus you return {Panel, State} from init. Thanks, yes I could do that. I guess it was just consistency. My main process does just that but the setup of each panel is a separate module with create_display/3. I didn't want to change the pattern just because this was a separate process. > /Dan > > On Sun, May 15, 2011 at 9:32 PM, Bob Cowdery wrote: >> Hi, >> >> This seems to initialise ok but is it the correct way to do things >> before I start implementing the main functions. >> >> I have a main wx processing using wx_object behaviour. This handles all >> the user interaction stuff. Now I want a separate process that will >> handle graphic displays. I create another wx_object process and start it >> from the main wx process >> >> The start/2 and init/2 of the graphic display. >> >> start(Env, Frame) -> >> wx_object:start_link({local, ?MODULE}, ?MODULE, [Env, Frame], []), >> {ok, self()}. >> >> init([Env, Frame]) -> >> io:format("~p starting~n", [?MODULE]), >> wx:set_env(Env), >> {Frame, #state{}}. >> >> I pass in wx:get_env() and the main frame of the main wx process as I >> don't want another frame. >> >> Then call from the main process (which is using AUI) to set up the >> drawing surface. >> >> handle_cast({create_display, Parent, Manager, Pane}, State) -> >> %% Canvas on which to build graphics >> Canvas = wxPanel:new(Parent, [{style, ?wxFULL_REPAINT_ON_RESIZE}]), >> ... >> >> Regards >> Bob >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> From dgud@REDACTED Mon May 16 11:37:07 2011 From: dgud@REDACTED (Dan Gudmundsson) Date: Mon, 16 May 2011 11:37:07 +0200 Subject: [erlang-questions] compiling R14B02 with WX support on Ubuntu 11.04 In-Reply-To: References: Message-ID: It seems to be a Ubuntu 11.04 problem with (proprietary) drivers. In my case /usr/lib/libGL.so is linked to mesa/libGL.so and not to nvidia-current/libGL.so which erlang-wx uses for dynamically loading all functions and extensions. But wxWidgets (and SDL) loads and creates the context with nvidia-current/libGL so two different GL implementations are used. Link /usr/lib/libGL.so to point to the correct nvidia-current/libGL.so and it works. IMHO this is a bug in (atleast) the nvidia package in ubuntu 11.04. I googled a bit and it seems other GL wrappers have the same problem in 11.04, so maybe someone should tell the ubuntu guys. /Dan 2011/5/13 Cyryl P?otnicki-Chudyk : > 2011/5/13 Boris M?hmer : >> Besides, could you check "wx:demo()", please? >> >> Especially the "gl" part... It crashes on my system. >> >> If it crashes on Your system as well, I would submit a bug report... >> >> > > works, except the gl part > wchich crashes the whole emulator > > 1> wx:demo(). > {wx_ref,35,wxFrame,<0.34.0>} > 2> > ? (Erlang:24191): Gtk-WARNING **: gtk_widget_size_allocate(): attempt > to allocate widget with width -5 and height 17 > > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(Erlang:24191): > Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget > with width -5 and height 17 > > ? ? ? ? ? ? ? ? ? ? ? (Erlang:24191): Gtk-WARNING **: > gtk_widget_size_allocate(): attempt to allocate widget with width -5 > and height 17 > > > Segmentation fault > > > -- > cyryl > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From travis.jensen@REDACTED Mon May 16 15:54:22 2011 From: travis.jensen@REDACTED (Travis Jensen) Date: Mon, 16 May 2011 07:54:22 -0600 Subject: [erlang-questions] api to retrieve module documentation (comparison to python shell) In-Reply-To: <4DC8E21E.50802@gmail.com> References: <4DC8E21E.50802@gmail.com> Message-ID: I agree docstrings are an amazingly valuable part of python. I doubt you'll find access to them in Erlang, since the compile step removes them. I wonder how hard it would be to patch the shell to look for the source of a .beam and parse it's docs. It would be nice to have a more immediate method than my 15 tab browser window or "man". Tj On May 10, 2011, at 12:58 AM, Todd wrote: > Is it possible to retrieve the documentation or the source for a given method? > > 1. I'd can to enumerate the loaded modules: > > (nitrogen@REDACTED)18> erlang:loaded(). > [sys_expand_pmod,eunit_autoexport,security_handler, > route_handler,role_handler,identity_handler,cache_handler, > eval_bits,cerl_trees,lib,action_hide,action_jquery_effect, > action_show,element_link,net_adm,process_registry_handler, > session_handler,element_placeholder,element_listitem, > element_bind,element_list,action_update,wf_validation, > element_span,processes,epp,log_handler,file_not_found_page, > re|...] > > 2. And I can get the exported methods for a given module: > > (nitrogen@REDACTED)25> [{exports, Exports}, _, _, _] = net_adm:module_info(). > [{exports,[{host_file,0}, > {localhost,0}, > {names,0}, > {names,1}, > {dns_hostname,1}, > {ping_list,1}, > {world,0}, > {world,1}, > {world_list,1}, > {world_list,2}, > {module_info,0}, > {module_info,1}, > {ping,1}]}, > {imports,[]}, > {attributes,[{vsn,[82065340652727412467812120004278067483]}]}, > {compile,[{options,[{cwd,"/home/user/erlang/otp_src_R14B02/lib/kernel/src"}, > {outdir,"/home/user/erlang/otp_src_R14B02/lib/kernel/src/../ebin"}, > {i,"/home/user/erlang/otp_src_R14B02/lib/kernel/src/../include"}, > debug_info]}, > {version,"4.7.3"}, > {time,{2011,4,26,3,21,35}}, > {source,"/home/user/erlang/otp_src_R14B02/lib/kernel/src/net_adm.erl"}]}] > (nitrogen@REDACTED)26> Exports. > [{host_file,0}, > {localhost,0}, > {names,0}, > {names,1}, > {dns_hostname,1}, > {ping_list,1}, > {world,0}, > {world,1}, > {world_list,1}, > {world_list,2}, > {module_info,0}, > {module_info,1}, > {ping,1}] > > 3. But now I'd like to get the docstring and/or the source for a given module:export. Is there an existing api method that does this? > > BTW - this is the sort of thing that python is really good at. I love being able to simply type "dir()" and navigate through the local environment and into objects. > > For example, running the python shell: > > a) look at the local environment > > >>> dir() > ['__builtins__', '__doc__', '__name__', '__package__'] > > b) examine an entry > > >>> dir (__doc__) > ['__class__', '__delattr__', '__doc__', '__format__', '__getattribute__', '__hash__', '__init__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__'] > > c) create an object > >>> a = [1,2,3] > > d) examine the object > >>> dir(a) > ['__add__', '__class__', '__contains__', '__delattr__', '__delitem__', '__delslice__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__getitem__', '__getslice__', '__gt__', '__hash__', '__iadd__', '__imul__', '__init__', '__iter__', '__le__', '__len__', '__lt__', '__mul__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__reversed__', '__rmul__', '__setattr__', '__setitem__', '__setslice__', '__sizeof__', '__str__', '__subclasshook__', 'append', 'count', 'extend', 'index', 'insert', 'pop', 'remove', 'reverse', 'sort'] > > > e) get the help on this object > >>> help(a) > > Help on list object: > > class list(object) > | list() -> new list > | list(sequence) -> new list initialized from sequence's items > | > | Methods defined here: > | > | __add__(...) > | x.__add__(y) <==> x+y > > > f) get help on a method: > >>> help(a.pop) > Help on built-in function pop: > > pop(...) > L.pop([index]) -> item -- remove and return item at index (default last). > Raises IndexError if list is empty or index is out of range. > > > This is amazingly useful. Is there anyway to have a similar experience in the erlang shell? > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From travis.jensen@REDACTED Mon May 16 16:09:44 2011 From: travis.jensen@REDACTED (Travis Jensen) Date: Mon, 16 May 2011 08:09:44 -0600 Subject: [erlang-questions] Odd behavior when sending emails via SMTP when messages are converted to/from binaries In-Reply-To: <20110516014104.GA11203@hijacked.us> References: <20110516014104.GA11203@hijacked.us> Message-ID: +1 on this. gen_smtp went into place trivially and just worked. tj On Sun, May 15, 2011 at 7:41 PM, Andrew Thompson wrote: > On Sat, May 14, 2011 at 07:34:52PM -0700, Chris Hicks wrote: > > > > I honestly don't know why I thought that there wasn't a list_to_binary > function...I suppose thats what you get for programming late into the night. > I believe it was on How I Met Your Mother that I heard the phrase "Nothing > good ever happens after 2am." I should probably take that to heart when it > comes to coding. > > > > Just out of curiosity, are you aware that libraries for constructing and > sending MIME email are already present as part of the gen_smtp project? > > Might save you some some time and further headaches. > > Andrew > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- *Travis Jensen* *** *Read the Software Maven @ http://softwaremaven.innerbrane.com/ Read my LinkedIn profile @ http://www.linkedin.com/in/travisjensen Read my Twitter mumblings @ http://twitter.com/SoftwareMaven Send me email @ travis.jensen@REDACTED **What kind of guy calls himself the Software Maven???** -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.r.nohl@REDACTED Mon May 16 16:33:47 2011 From: attila.r.nohl@REDACTED (Attila Rajmund Nohl) Date: Mon, 16 May 2011 16:33:47 +0200 Subject: [erlang-questions] api to retrieve module documentation (comparison to python shell) In-Reply-To: References: <4DC8E21E.50802@gmail.com> Message-ID: Hello! I think that's where an IDE comes into play. Even in vim you can press K on 'lists' and vim will show you the man page (not that it's that really useful if you're looking for only one particular function...). Of course, this can be improved, but I'm not sure this has to be done in the Erlang shell. 2011/5/16, Travis Jensen : > I agree docstrings are an amazingly valuable part of python. I doubt you'll > find access to them in Erlang, since the compile step removes them. > > I wonder how hard it would be to patch the shell to look for the source of a > .beam and parse it's docs. It would be nice to have a more immediate method > than my 15 tab browser window or "man". [...] From james.hague@REDACTED Mon May 16 16:49:21 2011 From: james.hague@REDACTED (James Hague) Date: Mon, 16 May 2011 09:49:21 -0500 Subject: [erlang-questions] Function Declaration Syntax In-Reply-To: References: Message-ID: On Sat, May 14, 2011 at 6:34 AM, Torben Hoffmann wrote: > This is - in my book - a step backwards. > You should haev the spec for the function and then pattern matching in the > function clauses since it gives you: > > Overview of what the function does. > 1st level overview of how the function branches out. > > This makes debugging so much faster than having to get inside a function > only to meet a case on the parameters as the first thing. My personal style: I keep everything in the function header if there are only a couple of parameters. If there are, say, four parameters to a function and only the first one is used for pattern matching, then I use "case." That makes it clear at a glance which parameters matter for matching and which are fixed. James From andrew@REDACTED Mon May 16 19:58:22 2011 From: andrew@REDACTED (Andrew Thompson) Date: Mon, 16 May 2011 13:58:22 -0400 Subject: [erlang-questions] Odd behavior when sending emails via SMTP when messages are converted to/from binaries In-Reply-To: References: <20110516014104.GA11203@hijacked.us> Message-ID: <20110516175822.GB11203@hijacked.us> On Mon, May 16, 2011 at 08:09:44AM -0600, Travis Jensen wrote: > +1 on this. gen_smtp went into place trivially and just worked. > Glad to hear it. Andrew From boris.muehmer@REDACTED Mon May 16 21:16:42 2011 From: boris.muehmer@REDACTED (=?UTF-8?Q?Boris_M=C3=BChmer?=) Date: Mon, 16 May 2011 21:16:42 +0200 Subject: [erlang-questions] compiling R14B02 with WX support on Ubuntu 11.04 In-Reply-To: References: Message-ID: You're right Dan, I just did some tests with the following drivers: - (default) nouveau - nvidia_current - nvidia_173 [- experimental 3D for nvidia cards (couldn't be installed on my system)] Using "nouveau" gave the "best results" for the "wx:demo()/gl-Example": it worked. [I had a crash with the gauge-Example, but I couldn't reproduce it (yet) to get a core dump.] But the "nouveau" driver isn't the best for more complex OpenGL applications/games (,yet). - boris 2011/5/16 Dan Gudmundsson : > It seems to be a Ubuntu 11.04 problem with (proprietary) drivers. > > In my case /usr/lib/libGL.so is linked to mesa/libGL.so and not to > nvidia-current/libGL.so > which erlang-wx uses for dynamically loading all functions and extensions. > > But wxWidgets (and SDL) loads and creates the context with > nvidia-current/libGL so > two different GL implementations are used. > > Link /usr/lib/libGL.so to point to the correct nvidia-current/libGL.so > and it works. > > IMHO this is a bug in (atleast) the nvidia package in ubuntu 11.04. > I googled ?a bit and it seems other GL wrappers have the same problem > in 11.04, so maybe someone > should tell the ubuntu guys. > > /Dan > > 2011/5/13 Cyryl P?otnicki-Chudyk : >> 2011/5/13 Boris M?hmer : >>> Besides, could you check "wx:demo()", please? >>> >>> Especially the "gl" part... It crashes on my system. >>> >>> If it crashes on Your system as well, I would submit a bug report... >>> >>> >> >> works, except the gl part >> wchich crashes the whole emulator >> >> 1> wx:demo(). >> {wx_ref,35,wxFrame,<0.34.0>} >> 2> >> ? (Erlang:24191): Gtk-WARNING **: gtk_widget_size_allocate(): attempt >> to allocate widget with width -5 and height 17 >> >> >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(Erlang:24191): >> Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget >> with width -5 and height 17 >> >> ? ? ? ? ? ? ? ? ? ? ? (Erlang:24191): Gtk-WARNING **: >> gtk_widget_size_allocate(): attempt to allocate widget with width -5 >> and height 17 >> >> >> Segmentation fault >> >> >> -- >> cyryl >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > From klas.johansson@REDACTED Mon May 16 21:48:37 2011 From: klas.johansson@REDACTED (Klas Johansson) Date: Mon, 16 May 2011 21:48:37 +0200 Subject: [erlang-questions] Erlang emacs workflow question In-Reply-To: References: Message-ID: On Thu, May 12, 2011 at 8:39 PM, Mike Oxford wrote: > Write some code > C-c C-k to make sure it compiles > Spin a release (using rebar) in another window > Run the code in another window > Is there a better/more streamlined way to do this, all from within emacs (I > have erl running in another window.) > Optimally it would be C-c C-k to compile it, maybe load the .beam, and test > directly from within emacs. > I feel like I'm missing something here... > Thanks! > -mox > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > Hi Mike, There are some options already available within the Erlang/OTP distribution. Don't know if you've seen these? They need (better) documentation to be easier to find and use, however. First, there's erlang-eunit which makes it quicker to work with eunit tests. Just edit your code or test and type "C-c C-e k" to compile both source code and test modules. Type "C-c C-e t" to toggle between the code and test. More bindings and options exist. Then there's erlang-flymake which will compile an erlang module and highlight any warnings and errors on the fly. This may require some customization if your project needs include files or beam files from other apps than the one currently being compiled. More details below. Hope that's a start. Cheers, Klas EUnit support ============= If you work a lot with eunit tests, these addons might come in handy. Add this to .emacs: (require 'erlang-eunit) Running test suites ------------------- C-c C-e k Compile the source and test files and run all EUnit tests in the module. C-c C-e t Switch to the src file if the EUnit test file is the current buffer and vice versa C-c C-e l Compile the source and test files and repeat the most recent EUnit test run. C-c C-e j Compile the source and test files and run the current EUnit test. Code coverage analysis ---------------------- C-c C-e c Compile the source and test files and run the EUnit test suite and measure code coverage. C-c C-e v Cover compile current module. C-c C-e a Analyze the data collected by cover tool for the module in the current buffer. Customization ------------- These variables alter the default behaviour of the eunit addons: erlang-eunit-src-candidate-dirs (default "../src" followed by ".") Names of directories which to search for source files matching an EUnit test file. The first directory in the list will be used, if there is no match. erlang-eunit-test-candidate-dirs (default "../test" followed by ".") Names of directories which to search for EUnit test files matching a source file. The first directory in the list will be used, if there is no match. erlang-eunit-autosave (default nil) Set to non-nil to automtically save unsaved buffers before running tests. This is useful, reducing the save-compile-load-test cycle to one keychord. On-the-fly syntax check ======================= This will compile source code on the fly (integrates with flymake) and give you instant feedback. Start using flymake with erlang by putting the following somewhere in your .emacs file: (require 'erlang-flymake) Flymake is rather eager and does its syntax checks frequently by default and if you are bothered by this, you might want to put the following in your .emacs as well: (erlang-flymake-only-on-save) There are a couple of variables which control the compilation options: erlang-flymake-command (default "erlc") The command that will be used to perform the syntax check. erlang-flymake-get-code-path-dirs-function This is the name of a function which shall return a list of ebin directories to add to the code path. Will by default return the compiled apps's ebin directory. erlang-flymake-get-include-dirs-function This is the name of a function which shall return a list of include directories to add to the include path. Will by default return the compiled apps's include directory. erlang-flymake-extra-opts A list of options that will be passed to the compiler. These are in there by default: warn_obsolete_guard warn_unused_import warn_shadow_vars warn_export_vars strong_validation report From shahrdad1@REDACTED Mon May 16 22:43:14 2011 From: shahrdad1@REDACTED (Shahrdad Shadab) Date: Mon, 16 May 2011 16:43:14 -0400 Subject: [erlang-questions] Erlangers in Montreal? In-Reply-To: <1305432181256-3523815.post@n4.nabble.com> References: <4D83B9A3.9050801@gmail.com> <1305432181256-3523815.post@n4.nabble.com> Message-ID: I am also doing Erlang for my own satisfaction. However i am in Toronto. Regards Shahrdad On Sun, May 15, 2011 at 12:03 AM, cognition.mind wrote: > I live in Gatineau, but sounds like an idea, > I just started learning erlang and have come to really love it, > > Keep me posted if anything gets moving. > > Cheers > Ramon > > ----- > Empires fall. Religions dissolve like mist. But quotes about monkeys with > keyboards live for eternity. > - The Covert Comic > -- > View this message in context: > http://erlang.2086793.n4.nabble.com/Erlangers-in-Montreal-tp3388272p3523815.html > Sent from the Erlang Questions mailing list archive at Nabble.com. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Tue May 17 00:48:45 2011 From: ok@REDACTED (Richard O'Keefe) Date: Tue, 17 May 2011 10:48:45 +1200 Subject: [erlang-questions] Function Declaration Syntax In-Reply-To: References: <3E5DD6BD-6129-4114-838C-6158CE886033@cs.otago.ac.nz> Message-ID: <41FF4CD8-00B1-408E-BBF7-583C5C5D02CC@cs.otago.ac.nz> On 16/05/2011, at 9:57 PM, Tony Finch wrote: > Richard O'Keefe wrote: >> >> An interesting alternative would be to allow >> >> fun F(N) when is_integer(N), N > 1 -> F(N-1) + F(N-2) >> ; F(1) -> 1 >> ; F(0) -> 1 >> end >> >> and if the variable here were optional (either appearing in all >> clauses or disappearing in all clauses) it would be clear that the >> traditional form has a consistently repeated but invisible name. > > A tangential observation ... > http://bosker.wordpress.com/2011/04/29/the-worst-algorithm-in-the-world/ The example was intended to be RECOGNISABLE, not EFFICIENT. I've been intimately familiar with the logarithmic method for the last 30 years or more, and the closed-form solution (and how to derive it and similar solutions to related problems) for at least another 10 years before that. I could have just said "think of the difference between LET and named-LET in Scheme." From moxford@REDACTED Tue May 17 03:13:47 2011 From: moxford@REDACTED (Mike Oxford) Date: Mon, 16 May 2011 18:13:47 -0700 Subject: [erlang-questions] gproc_dist activation Message-ID: I seem to be stuck in "local_only" mode, testing on a single stand-alone node. I do not see where I can force an election, and get access to gproc_dist. What is the recommended way to move from local to global? Thanks! -mox -------------- next part -------------- An HTML attachment was scrubbed... URL: From yaohui1984@REDACTED Tue May 17 03:38:21 2011 From: yaohui1984@REDACTED (=?ISO-8859-1?B?eWFvaHVp?=) Date: Tue, 17 May 2011 09:38:21 +0800 Subject: [erlang-questions] About error enfile? Message-ID: I do a test C1000k, when connections reach to 540k, I got a error {badmatch,{error,enfile}}. {error,enfile} this error represents the files tables is full (for the entire OS) but my kernel ulimit -n 800000 cat /proc/sys/fs/file-max 2215800 {error,enfile} is this error means other problem? -------------- next part -------------- An HTML attachment was scrubbed... URL: From gregory.haskins@REDACTED Tue May 17 04:37:18 2011 From: gregory.haskins@REDACTED (Gregory Haskins) Date: Mon, 16 May 2011 22:37:18 -0400 Subject: [erlang-questions] gproc_dist activation In-Reply-To: References: Message-ID: <4DD1DF5E.5070504@gmail.com> Hi Mike, On 5/16/11 9:13 PM, Mike Oxford wrote: > I seem to be stuck in "local_only" mode, testing on a single stand-alone > node. > > I do not see where I can force an election, and get access to gproc_dist. > > What is the recommended way to move from local to global? You need to ensure that you set the "gproc_dist" environment variable on the "gproc" app to something appropriate. You can use 'all', an explicit list of the nodes, or point it at a seed node which IIUC will gossip the membership of the others. For instance: -gproc gproc_dist 'all' -gproc gproc_dist "{[], [{seed, 'controller@REDACTED'}]}" Kind Regards, -Greg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 267 bytes Desc: OpenPGP digital signature URL: From francis.joanis@REDACTED Tue May 17 05:53:16 2011 From: francis.joanis@REDACTED (Francis Joanis) Date: Mon, 16 May 2011 23:53:16 -0400 Subject: [erlang-questions] Erlangers in Montreal? In-Reply-To: References: <4D83B9A3.9050801@gmail.com> <1305432181256-3523815.post@n4.nabble.com> Message-ID: Hi, We should probably all join the Erlang User Group Canada subgroup (EUG-Canada) on LinkedIn. Cheers, Francis -------------- next part -------------- An HTML attachment was scrubbed... URL: From travis.jensen@REDACTED Tue May 17 07:02:41 2011 From: travis.jensen@REDACTED (Travis Jensen) Date: Mon, 16 May 2011 23:02:41 -0600 Subject: [erlang-questions] api to retrieve module documentation (comparison to python shell) In-Reply-To: References: <4DC8E21E.50802@gmail.com> Message-ID: <8124333962264608262@unknownmsgid> I'll have to figure out how to make emacs smarter about that. Can't imagine I'm the first, and that's where I run most of my Erlang shells from anyway. Tj - Travis Jensen Sent from my iPad (yup, you know it) On May 16, 2011, at 8:33 AM, Attila Rajmund Nohl wrote: > Hello! > > I think that's where an IDE comes into play. Even in vim you can press > K on 'lists' and vim will show you the man page (not that it's that > really useful if you're looking for only one particular function...). > Of course, this can be improved, but I'm not sure this has to be done > in the Erlang shell. > > 2011/5/16, Travis Jensen : >> I agree docstrings are an amazingly valuable part of python. I doubt you'll >> find access to them in Erlang, since the compile step removes them. >> >> I wonder how hard it would be to patch the shell to look for the source of a >> .beam and parse it's docs. It would be nice to have a more immediate method >> than my 15 tab browser window or "man". > [...] > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From dangud@REDACTED Tue May 17 08:09:50 2011 From: dangud@REDACTED (Dan Gudmundsson) Date: Tue, 17 May 2011 08:09:50 +0200 Subject: [erlang-questions] api to retrieve module documentation (comparison to python shell) In-Reply-To: <8124333962264608262@unknownmsgid> References: <4DC8E21E.50802@gmail.com> <8124333962264608262@unknownmsgid> Message-ID: (add-hook 'erlang-mode-hook 'my-erlang-mode-hook) (defun my-erlang-mode-hook () (local-set-key "\C-cm" 'erlang-man-function)) Makes "C-c m" jump to documentation for module function. I have been thinking of adding this shortcut to the emacs mode. /Dan On Tue, May 17, 2011 at 7:02 AM, Travis Jensen wrote: > I'll have to figure out how to make emacs smarter about that. Can't > imagine I'm the first, and that's where I run most of my Erlang shells > from anyway. > > Tj > > - > Travis Jensen > > Sent from my iPad (yup, you know it) > > On May 16, 2011, at 8:33 AM, Attila Rajmund Nohl > wrote: > >> Hello! >> >> I think that's where an IDE comes into play. Even in vim you can press >> K on 'lists' and vim will show you the man page (not that it's that >> really useful if you're looking for only one particular function...). >> Of course, this can be improved, but I'm not sure this has to be done >> in the Erlang shell. >> >> 2011/5/16, Travis Jensen : >>> I agree docstrings are an amazingly valuable part of python. ?I doubt you'll >>> find access to them in Erlang, since the compile step removes them. >>> >>> I wonder how hard it would be to patch the shell to look for the source of a >>> .beam and parse it's docs. It would be nice to have a more immediate method >>> than my 15 tab browser window or "man". >> [...] >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From yaohui1984@REDACTED Tue May 17 08:32:13 2011 From: yaohui1984@REDACTED (=?ISO-8859-1?B?eWFvaHVp?=) Date: Tue, 17 May 2011 14:32:13 +0800 Subject: [erlang-questions] About error enfile? Message-ID: It's a problem 800000 < 1000K, but connections are less than 540k cat /proc/sys/fs/file-nr result 416 0 4821388 ulimit -n 800000? 800000 < 1000K. Is this the problem? What about cat /proc/sys/fs/file-nr? On Tue, May 17, 2011 at 9:38 AM, yaohui wrote: I do a test C1000k, when connections reach to 540k, I got a error {badmatch,{error,enfile}}. {error,enfile} this error represents the files tables is full (for the entire OS) but my kernel ulimit -n 800000 cat /proc/sys/fs/file-max 2215800 {error,enfile} is this error means other problem? _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From wsongcn@REDACTED Tue May 17 08:39:34 2011 From: wsongcn@REDACTED (Andy W. Song) Date: Tue, 17 May 2011 14:39:34 +0800 Subject: [erlang-questions] Please discard Message-ID: Just a test of my subscription. Please skip. Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From wsongcn@REDACTED Tue May 17 08:43:40 2011 From: wsongcn@REDACTED (Andy W. Song) Date: Tue, 17 May 2011 14:43:40 +0800 Subject: [erlang-questions] About error enfile? In-Reply-To: References: Message-ID: out of socket memory says something. I think you can keep watching /proc/sys/fs/file-nr and /proc/net/sockstat during test. On Tue, May 17, 2011 at 2:40 PM, yaohui wrote: > /proc/sys/fs/file-nr "416 0 4821388" is right now, I'll do a > test again while observing this parameter > > dmesg print a lot log > out of socket memory > > Can you post the output of "dmesg" which might include some OS warning > messages. > > "416 0 4821388" is some time after this happened, right? It shows > that there aren't many files open. > > Andy > > On Tue, May 17, 2011 at 2:32 PM, yaohui wrote: > >> It's a problem 800000 < 1000K, but connections are less than 540k >> >> cat /proc/sys/fs/file-nr result >> 416 0 4821388 >> >> ulimit -n 800000? >> 800000 < 1000K. >> Is this the problem? >> What about cat /proc/sys/fs/file-nr? >> >> On Tue, May 17, 2011 at 9:38 AM, yaohui wrote: >> >>> I do a test C1000k, when connections reach to 540k, I got a error >>> {badmatch,{error,enfile}}. >>> {error,enfile} this error represents the files tables is full (for the >>> entire OS) >>> but my kernel >>> ulimit -n >>> 800000 >>> cat /proc/sys/fs/file-max >>> 2215800 >>> >>> {error,enfile} is this error means other problem? >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wsong.cn@REDACTED Tue May 17 08:44:43 2011 From: wsong.cn@REDACTED (Wenqiang Song) Date: Tue, 17 May 2011 14:44:43 +0800 Subject: [erlang-questions] Please discard Message-ID: Just a test of my subscription. Please skip. -------------- next part -------------- An HTML attachment was scrubbed... URL: From yaohui1984@REDACTED Tue May 17 08:49:57 2011 From: yaohui1984@REDACTED (=?gbk?B?eWFvaHVp?=) Date: Tue, 17 May 2011 14:49:57 +0800 Subject: [erlang-questions] =?gbk?b?u9i4tKO6IEFib3V0IGVycm9yIGVuZmlsZT8=?= Message-ID: ok, thanks. out of socket memory says something. I think you can keep watching /proc/sys/fs/file-nr and /proc/net/sockstat during test. On Tue, May 17, 2011 at 2:40 PM, yaohui wrote: /proc/sys/fs/file-nr "416 0 4821388" is right now, I'll do a test again while observing this parameter dmesg print a lot log out of socket memory Can you post the output of "dmesg" which might include some OS warning messages. "416 0 4821388" is some time after this happened, right? It shows that there aren't many files open. Andy On Tue, May 17, 2011 at 2:32 PM, yaohui wrote: It's a problem 800000 < 1000K, but connections are less than 540k cat /proc/sys/fs/file-nr result 416 0 4821388 ulimit -n 800000? 800000 < 1000K. Is this the problem? What about cat /proc/sys/fs/file-nr? On Tue, May 17, 2011 at 9:38 AM, yaohui wrote: I do a test C1000k, when connections reach to 540k, I got a error {badmatch,{error,enfile}}. {error,enfile} this error represents the files tables is full (for the entire OS) but my kernel ulimit -n 800000 cat /proc/sys/fs/file-max 2215800 {error,enfile} is this error means other problem? _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From langxianzhe@REDACTED Tue May 17 09:48:27 2011 From: langxianzhe@REDACTED (=?GB2312?B?wMnPzM7k?=) Date: Tue, 17 May 2011 15:48:27 +0800 Subject: [erlang-questions] [Erlang]about "apply" function in the erlang.erl Message-ID: hi, I see "apply" function invoke "apply?function in the "erlang.erl". I can`t understand it. Who can explain for me? Thanks. 57 apply(Fun, Args) -> 58 apply(Fun, Args). 59 60 apply(Mod, Name, Args) -> 61 apply(Mod, Name, Args). -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.kleberg@REDACTED Tue May 17 09:51:36 2011 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Tue, 17 May 2011 09:51:36 +0200 Subject: [erlang-questions] [Erlang]about "apply" function in the erlang.erl In-Reply-To: References: Message-ID: <1305618696.4854.9.camel@seasc1137> Greetings, apply is a built in function (BIF). It is implemented in C, not Erlang. bengt On Tue, 2011-05-17 at 09:48 +0200, ??? wrote: > hi, > I see "apply" function invoke "apply?function in the "erlang.erl". > I can`t understand it. > Who can explain for me? Thanks. > > > 57 apply(Fun, Args) -> > 58 apply(Fun, Args). > 59 > 60 apply(Mod, Name, Args) -> > 61 apply(Mod, Name, Args). > > From langxianzhe@REDACTED Tue May 17 10:00:42 2011 From: langxianzhe@REDACTED (jasonlxw) Date: Tue, 17 May 2011 01:00:42 -0700 (PDT) Subject: [erlang-questions] [Erlang]about "apply" function in the erlang.erl In-Reply-To: <1305618696.4854.9.camel@seasc1137> References: <1305618696.4854.9.camel@seasc1137> Message-ID: ok,Thanks. Which is apply a built in function (BIF) 2011/5/17 Bengt Kleberg [via Erlang] < ml-node+3528358-559382299-67370@REDACTED> > Greetings, > > apply is a built in function (BIF). It is implemented in C, not Erlang. > > > bengt > > On Tue, 2011-05-17 at 09:48 +0200, ??? wrote: > > > hi, > > I see "apply" function invoke "apply?function in the "erlang.erl". > > I can`t understand it. > > Who can explain for me? Thanks. > > > > > > 57 apply(Fun, Args) -> > > 58 apply(Fun, Args). > > 59 > > 60 apply(Mod, Name, Args) -> > > 61 apply(Mod, Name, Args). > > > > > > _______________________________________________ > erlang-questions mailing list > [hidden email] > http://erlang.org/mailman/listinfo/erlang-questions > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://erlang.2086793.n4.nabble.com/Erlang-about-apply-function-in-the-erlang-erl-tp3528347p3528358.html > To start a new topic under Erlang Questions, email > ml-node+2086794-1604045721-67370@REDACTED > To unsubscribe from Erlang Questions, click here. > > ----- Never give up -- View this message in context: http://erlang.2086793.n4.nabble.com/Erlang-about-apply-function-in-the-erlang-erl-tp3528347p3528381.html Sent from the Erlang Questions mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From masklinn@REDACTED Tue May 17 10:18:50 2011 From: masklinn@REDACTED (Masklinn) Date: Tue, 17 May 2011 10:18:50 +0200 Subject: [erlang-questions] [Erlang]about "apply" function in the erlang.erl In-Reply-To: <1305618696.4854.9.camel@seasc1137> References: <1305618696.4854.9.camel@seasc1137> Message-ID: <982190EF-20C7-424D-9CEE-1062D8E354E4@masklinn.net> On 2011-05-17, at 09:51 , Bengt Kleberg wrote: > Greetings, > > apply is a built in function (BIF). It is implemented in C, not Erlang. Does it work in a similar manner to that of Smalltalks, or differently? In Smalltalks, `Boolean ifTrue: aBlock ifFalse: aBlock` literal forms are usually compiled to call into native code directly, so the implementation of this message in Smalltalk code in Smalltalk VMs looks like this: ifTrue:trueBlock ifFalse:falseBlock ^self ifTrue:[ trueBlock call ] ifFalse: [ falseBlock call ] which looks like it would not work, but when the form `var ifTrue:aBlockLiteral ifFalse:aBlockLiteral` is encountered the Smalltalk compiler takes over and replaces this with native code. So the Smalltalk implementation is only ever hit for non-literal sends (either non-literal blocks, or usage of selectors), and its only role is to redirect execution to the native version. Is the purpose (and behavior) of the pure version of erlang:apply similar? From sasa555@REDACTED Tue May 17 12:20:07 2011 From: sasa555@REDACTED (sasa) Date: Tue, 17 May 2011 12:20:07 +0200 Subject: [erlang-questions] mochiweb https/ssl In-Reply-To: <1304632965.1894.13.camel@sasa-laptop> References: <1304632965.1894.13.camel@sasa-laptop> Message-ID: Hello, I spent last week fighting with SSL problems without success. Eventually I switched to the stunnel based SSL which delegates to Erlang HTTP server. Following are the characteristics of the behavior I experienced last week. These are a bit different than the original ones, but I didn't want to open new topic. I am posting this in case someone is stuck with the similar behavior. 1. The mochiweb http server runs without problems since the beginning of the year. It also servers some small number of SSL users. The server is the same erlang application running on the same node. 2. Every day of the last week, in the morning, I would force the users to use SSL (https) rather than http. 3. The server then works fine for couple of hours. 4. At one point, the servers starts responding very slowly. Restart of the erlang application, node, or even the machine doesn't help. 5. At the same time, the http server (which is the same application on the same node) is working fine. 6. Kernel tuning didn't help. 7. I don't notice anything strange in erlang log or on the OS level. 8. In my application log, it seems as if most connections are not even established. The same thing is confirmed from netstat output. The number of connections is smaller than expected. It looks as if new requests are queued somewhere or some main accept/listen loop is processing them slowly. 9. The CPU usage is low as well as the memory usage. After forcing users back to http, the problems disappeared. The server could then normally serve smaller number of SSL users. It seems to me that the problem is somewhere in the mochiweb/erlang. After switching to stunnel, which is in front of that same mochiweb application, everything is working nicely. I should note that stunnel uses more CPU. I am not quite sure why is it not working for me. I had load tests which performed fine. Maybe the problem is that my real users are constantly connecting/disconnecting, closing browsers during the request etc. I didn't load test this type of users. In any case, the behavior described above occurred every day, and was resolved when switching to stunnel SSL. I am sorry it didn't work out for me. I would be happier to use erlang SSL, so I'll try again when the new version is released. Regards, Sasa On Fri, May 6, 2011 at 12:02 AM, sasa wrote: > Hello, > > First of all, I apologize if this question occurs twice. I have tried > submitting it couple of hours ago via google groups, but it didn't show up, > so I'm trying via e-mail now. > > I am trying to develop https comet (long polling) server using mochiweb. I > have already written one such http server which is in production for couple > of months and serves no more than 1000 concurrent users, sending broadcast > message to all concurrent users at an average rate of 0.3 broadcast/sec > > When I added ssl support, it essentially works when smaller number of users > (about 100-200) are connected. With larger number, it stops responding > correctly i.e. some connection attempts are refused, requests time out etc.Only ssl/https part seems to be affected by this behavior. > > To better test this, I developed small test mochiweb app which works as > follows: > 1. Spawn and register singleton broadcast process > 2. For each request, the erlang process sends its pid to the broadcast > process. Then it waits for the message from the broadcast process > 3. Every 5 seconds broadcast process notifies all registered https response > processes from 2, then it clears its list of registered processes > 4. When process from 2 receives notification, it responds and finishes. > > In this test implementation, the response is hardcoded short string. For > the sake of brevity, I didn't include the test app code, but if necessary I > can do so. > > > I then deployed this test app to the server, and set up two client > machines to load test the server. The load testing code is also written in > erlang, and is using ibrowse for making https requests, since I had some > problems with httpc. The test client basically adheres to the protocol > described above. It spawns request processes, with each process making the > requests in an infinite loop. I gather success/failure stats in a s > ingleton erlang process and print them out in regular intervals. > > As in the production system, with http, the test server performs > correctly. With https, when number of concurrent requests reaches some > treshold (about 1000), many requests are not served. > > On the client machine, I occasionally receive following errors: > =ERROR REPORT==== > ** State machine <0.17592.0> terminating > > ** Reason for termination = > ** {badarg,[{erlang,byte_size,[undefined]}, > {ssl_tls1,split_secret,1}, > {ssl_tls1,prf,4}, > {ssl_handshake,master_secret,4}, > {ssl_connection,handle_resumed_session,2}, > {ssl_connection,next_state,3}, > {gen_fsm,handle_msg,7}, > {proc_lib,init_p_do_apply,3}]} > > > While on the server I occasionally notice following errors: > =SUPERVISOR REPORT==== 5-May-2011::11:06:33 === > Supervisor: {local,ssl_connection_sup} > Context: child_terminated > Reason: {{badmatch,{resumed,undefined}}, > [{ssl_handshake,hello,4}, > {ssl_connection,hello,2}, > {ssl_connection,next_state,3}, > {gen_fsm,handle_msg,7}, > {proc_lib,init_p_do_apply,3}]} > Offender: [{pid,<0.7044.2>}, > {name,undefined}, > {mfargs,{ssl_connection,start_link,undefined}}, > {restart_type,temporary}, > {shutdown,4000}, > {child_type,worker}] > > > I have tried to tweak some OS parameters, as well as erlang parameters, but > without success. After three days of experimenting, I am out of ideas and > need some help or pointers. > > I am using Erlang R14B02 on 64 bit Ubuntu 10.04, all the machines are on > the EC2 cloud. > > Following are sysctl.conf settings (I tried some more combinations without > success): > net.core.rmem_max = 16777216 > net.core.wmem_max = 16777216 > net.ipv4.tcp_rmem = 4096 87380 16777216 > net.ipv4.tcp_wmem = 4096 65536 16777216 > net.ipv4.tcp_syncookies = 1 > > net.ipv4.tcp_mem = 50576 64768 98152 > net.core.netdev_max_backlog = 2500 > net.ipv4.netfilter.ip_conntrack_max = 1048576 > > net.ipv4.ip_local_port_range = 1024 65535 > > net.ipv4.tcp_fin_timeout = 10 > > > > Following is ulimit -a output: > core file size (blocks, -c) 0 > data seg size (kbytes, -d) unlimited > scheduling priority (-e) 20 > file size (blocks, -f) unlimited > pending signals (-i) 16382 > max locked memory (kbytes, -l) 64 > max memory size (kbytes, -m) unlimited > open files (-n) 32000 > pipe size (512 bytes, -p) 8 > POSIX message queues (bytes, -q) 819200 > real-time priority (-r) 0 > stack size (kbytes, -s) 8192 > cpu time (seconds, -t) unlimited > max user processes (-u) unlimited > virtual memory (kbytes, -v) unlimited > file locks (-x) unlimited > > > > These are mochiweb parameters: > [ > {port, 9999}, > {name, https_test}, > {ssl, true}, > {ssl_opts, [ > {cacertfile, "keys/cacert.pem"}, > {certfile, "keys/cert.pem"}, > {keyfile, "keys/cert.key"}, > {depth, 0} > ]} > ] > > > To use it on a 443 port, I have set up iptables port forwarding > iptables -t nat -I PREROUTING --source 0/0 --destination 0/0 -p tcp --dport > 443 -j REDIRECT --to-ports 9999 > > > These are erl parameters: > erl -P 268435456 -env ERL_MAX_PORTS 100000 > > > > If anybody has any idea, I would be most grateful. > > > Best regards, > Sasa > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan@REDACTED Tue May 17 12:41:01 2011 From: ivan@REDACTED (Ivan Uemlianin) Date: Tue, 17 May 2011 11:41:01 +0100 Subject: [erlang-questions] How to use Pman for looking at process state Message-ID: <4DD250BD.206@llaisdy.com> Dear All I'm using Pman to look at a running erlang application. Many of the processes are running functions in receive loops like the following: myFunc(State) -> receive % some clauses defining NewState end, myFunc(NewState). Tracing a process allows me to see the messages received by and sent from the process. Is there any way I can see the value of State? If not, is there another to see the value of process variables? With thanks and best wishes Ivan -- ============================================================ Ivan A. Uemlianin Speech Technology Research and Development ivan@REDACTED www.llaisdy.com llaisdy.wordpress.com www.linkedin.com/in/ivanuemlianin "Froh, froh! Wie seine Sonnen, seine Sonnen fliegen" (Schiller, Beethoven) ============================================================ From bengt.kleberg@REDACTED Tue May 17 12:44:58 2011 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Tue, 17 May 2011 12:44:58 +0200 Subject: [erlang-questions] [Erlang]about "apply" function in the erlang.erl In-Reply-To: References: <1305618696.4854.9.camel@seasc1137> Message-ID: <1305629098.4854.14.camel@seasc1137> Greetings, You need apply if you do not know the number of arguments. bengt On Tue, 2011-05-17 at 10:39 +0200, Andy W. Song wrote: > Why do we need apply? Can't we just invoke the function directly? > > > Thanks > Andy > > On Tue, May 17, 2011 at 3:51 PM, Bengt Kleberg > wrote: > Greetings, > > apply is a built in function (BIF). It is implemented in C, > not Erlang. > > > bengt > > > On Tue, 2011-05-17 at 09:48 +0200, ??? wrote: > > hi, > > I see "apply" function invoke "apply?function in the > "erlang.erl". > > I can`t understand it. > > Who can explain for me? Thanks. > > > > > > 57 apply(Fun, Args) -> > > 58 apply(Fun, Args). > > 59 > > 60 apply(Mod, Name, Args) -> > > 61 apply(Mod, Name, Args). > > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > From bengt.kleberg@REDACTED Tue May 17 12:46:29 2011 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Tue, 17 May 2011 12:46:29 +0200 Subject: [erlang-questions] How to use Pman for looking at process state In-Reply-To: <4DD250BD.206@llaisdy.com> References: <4DD250BD.206@llaisdy.com> Message-ID: <1305629190.4854.16.camel@seasc1137> Greetings, If there is no way to use pman for this I recommend dbg. Trace on myFunc. bengt On Tue, 2011-05-17 at 12:41 +0200, Ivan Uemlianin wrote: > Dear All > > I'm using Pman to look at a running erlang application. Many of the > processes are running functions in receive loops like the following: > > myFunc(State) -> > receive > % some clauses defining NewState > end, > myFunc(NewState). > > Tracing a process allows me to see the messages received by and sent > from the process. Is there any way I can see the value of State? If > not, is there another to see the value of process variables? > > With thanks and best wishes > > Ivan > > From the.malkolm@REDACTED Tue May 17 13:04:58 2011 From: the.malkolm@REDACTED (Alexander Krasnukhin) Date: Tue, 17 May 2011 13:04:58 +0200 Subject: [erlang-questions] 'reply-to' header in this mailing list Message-ID: Hej, Why this mailing list doesn't add itself to the 'reply-to' header? I see it isn't uncommon for subscribers to send message to the author directly instead of the list. I wonder why? -- Regards, Alexander -------------- next part -------------- An HTML attachment was scrubbed... URL: From mazen.harake@REDACTED Tue May 17 13:24:29 2011 From: mazen.harake@REDACTED (Mazen Harake) Date: Tue, 17 May 2011 13:24:29 +0200 Subject: [erlang-questions] 'reply-to' header in this mailing list In-Reply-To: References: Message-ID: This has been debated for as long as mailing lists have been used. This is a philosophical question. To shortcut the discussion which will probably develop now: Use "reply all". Everyone should learn this. The other way is simply a hack. See: http://www.metasystema.net/essays/reply-to.html /M On 17 May 2011 13:04, Alexander Krasnukhin wrote: > Hej, > > Why this mailing list doesn't add itself to the 'reply-to' header? I see it > isn't uncommon for subscribers to send message to the author directly > instead of the list. > > I wonder why? > > -- > Regards, > Alexander > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mazen.harake@REDACTED Tue May 17 13:29:25 2011 From: mazen.harake@REDACTED (Mazen Harake) Date: Tue, 17 May 2011 13:29:25 +0200 Subject: [erlang-questions] 'reply-to' header in this mailing list In-Reply-To: References: Message-ID: To clarify. The link is FOR when you suggest, not against. I was sending it as an example of the philosophical discussion people have about it. On 17 May 2011 13:24, Mazen Harake wrote: > This has been debated for as long as mailing lists have been used. This is > a philosophical question. > > To shortcut the discussion which will probably develop now: Use "reply > all". > > Everyone should learn this. The other way is simply a hack. > > See: http://www.metasystema.net/essays/reply-to.html > > /M > > > On 17 May 2011 13:04, Alexander Krasnukhin wrote: > >> Hej, >> >> Why this mailing list doesn't add itself to the 'reply-to' header? I see >> it isn't uncommon for subscribers to send message to the author directly >> instead of the list. >> >> I wonder why? >> >> -- >> Regards, >> Alexander >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamie@REDACTED Tue May 17 13:30:26 2011 From: jamie@REDACTED (Jamie Brandon) Date: Tue, 17 May 2011 19:30:26 +0800 Subject: [erlang-questions] opaque type definition makes dialyzer unhappy even in same module In-Reply-To: References: Message-ID: I ran into the same problem a few days ago. Dialyzer doesn't like opaque types which are simple aliases. if you add a tag (and modify the rest of the code accordingly) it should work fine: -type fib_heap() :: {fib_heap, [fib_heap_node()]}. This will also make debugging easier if fib_heap shows up in an error report. On 16 May 2011 04:16, Hynek Vychodil wrote: > Hi, > > I'm playing with dialyzer in mine attempt to fibonacci heap > implementation and I got weird behavior. When I define fib_heap() as > type dialyzer seems happy but when I change it to -opaque it produce > warnings below > > $ dialyzer fib_heap.erl > ?Checking whether the PLT /home/hynek/.dialyzer_plt is up-to-date... yes > ?Proceeding with analysis... > fib_heap.erl:32: The call fib_heap:reset_min_(H::[any()]) does not > have an opaque term of type fib_heap:fib_heap() as 1st argument > fib_heap.erl:46: The call fib_heap:reset_min_(T::[any()],H::any(),[]) > does not have opaque terms as 1st and 3rd arguments > fib_heap.erl:53: The call > fib_heap:reset_min_(T::[any()],H::{_,_},[any(),...]) does not have > opaque terms as 1st and 3rd arguments > fib_heap.erl:55: The call > fib_heap:reset_min_(T::[any()],Min::any(),[any(),...]) does not have > opaque terms as 1st and 3rd arguments > fib_heap.erl:64: The call > fib_heap:compact_(nonempty_maybe_improper_list(),array()) does not > have an opaque term of type fib_heap:fib_heap() as 1st argument > ?done in 0m0.72s > done (warnings were emitted) > > What is going on? According to documentation: "Types declared as > opaque represent sets of terms whose structure is not supposed to be > visible in any way outside of their defining module (i.e., only the > module defining them is allowed to depend on their term structure)." I > only changed '-type' to '-opaque' on line 8, I stay in same module but > dialyzer emits warnings which I don't understand and don't know how I > should fix or suppress. > > -- > --Hynek (Pichi) Vychodil > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > From the.malkolm@REDACTED Tue May 17 13:50:24 2011 From: the.malkolm@REDACTED (Alexander Krasnukhin) Date: Tue, 17 May 2011 13:50:24 +0200 Subject: [erlang-questions] 'reply-to' header in this mailing list In-Reply-To: References: Message-ID: I don't want to discuss this. Just wanted to ask why because it is unusual these days. On Tue, May 17, 2011 at 1:24 PM, Mazen Harake wrote: > This has been debated for as long as mailing lists have been used. This is > a philosophical question. > > To shortcut the discussion which will probably develop now: Use "reply > all". > > Everyone should learn this. The other way is simply a hack. > > See: http://www.metasystema.net/essays/reply-to.html > > /M > > > On 17 May 2011 13:04, Alexander Krasnukhin wrote: > >> Hej, >> >> Why this mailing list doesn't add itself to the 'reply-to' header? I see >> it isn't uncommon for subscribers to send message to the author directly >> instead of the list. >> >> I wonder why? >> >> -- >> Regards, >> Alexander >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -- Regards, Alexander -------------- next part -------------- An HTML attachment was scrubbed... URL: From mazen.harake@REDACTED Tue May 17 13:58:47 2011 From: mazen.harake@REDACTED (Mazen Harake) Date: Tue, 17 May 2011 13:58:47 +0200 Subject: [erlang-questions] 'reply-to' header in this mailing list In-Reply-To: References: Message-ID: http://erlang.2086793.n4.nabble.com/mailing-list-quot-reply-to-quot-td3067987.html See David Mercer's response. /M On 17 May 2011 13:50, Alexander Krasnukhin wrote: > I don't want to discuss this. Just wanted to ask why because it is unusual > these days. > > > On Tue, May 17, 2011 at 1:24 PM, Mazen Harake wrote: > >> This has been debated for as long as mailing lists have been used. This is >> a philosophical question. >> >> To shortcut the discussion which will probably develop now: Use "reply >> all". >> >> Everyone should learn this. The other way is simply a hack. >> >> See: http://www.metasystema.net/essays/reply-to.html >> >> /M >> >> >> On 17 May 2011 13:04, Alexander Krasnukhin wrote: >> >>> Hej, >>> >>> Why this mailing list doesn't add itself to the 'reply-to' header? I see >>> it isn't uncommon for subscribers to send message to the author directly >>> instead of the list. >>> >>> I wonder why? >>> >>> -- >>> Regards, >>> Alexander >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >> > > > -- > Regards, > Alexander > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From the.malkolm@REDACTED Tue May 17 14:03:18 2011 From: the.malkolm@REDACTED (Alexander Krasnukhin) Date: Tue, 17 May 2011 14:03:18 +0200 Subject: [erlang-questions] 'reply-to' header in this mailing list In-Reply-To: References: Message-ID: Yeah, yeah. I've got this. It is some kind of local joke. Don't have anything to ask? Why not just ask why the hell "reply-to" isn't the mailing list address itself? On Tue, May 17, 2011 at 1:58 PM, Mazen Harake wrote: > > http://erlang.2086793.n4.nabble.com/mailing-list-quot-reply-to-quot-td3067987.html > > See David Mercer's response. > > /M > > > On 17 May 2011 13:50, Alexander Krasnukhin wrote: > >> I don't want to discuss this. Just wanted to ask why because it is unusual >> these days. >> >> >> On Tue, May 17, 2011 at 1:24 PM, Mazen Harake wrote: >> >>> This has been debated for as long as mailing lists have been used. This >>> is a philosophical question. >>> >>> To shortcut the discussion which will probably develop now: Use "reply >>> all". >>> >>> Everyone should learn this. The other way is simply a hack. >>> >>> See: http://www.metasystema.net/essays/reply-to.html >>> >>> /M >>> >>> >>> On 17 May 2011 13:04, Alexander Krasnukhin wrote: >>> >>>> Hej, >>>> >>>> Why this mailing list doesn't add itself to the 'reply-to' header? I see >>>> it isn't uncommon for subscribers to send message to the author directly >>>> instead of the list. >>>> >>>> I wonder why? >>>> >>>> -- >>>> Regards, >>>> Alexander >>>> >>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>>> >>> >> >> >> -- >> Regards, >> Alexander >> >> > -- Regards, Alexander -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimo+erlang-questions@REDACTED Tue May 17 16:28:48 2011 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Tue, 17 May 2011 16:28:48 +0200 Subject: [erlang-questions] 'reply-to' header in this mailing list In-Reply-To: References: Message-ID: <20110517142848.GA9263@erix.ericsson.se> Search the archives. Do not waste bandwidth. The same bottom line as the last time still applies: http://erlang.org/pipermail/erlang-questions/2010-December/055017.html / Raimo Niskanen, mailing list maintainer at erlang dot org On Tue, May 17, 2011 at 02:03:18PM +0200, Alexander Krasnukhin wrote: > Yeah, yeah. I've got this. It is some kind of local joke. Don't have > anything to ask? Why not just ask why the hell "reply-to" isn't the mailing > list address itself? > > On Tue, May 17, 2011 at 1:58 PM, Mazen Harake wrote: > > > > > http://erlang.2086793.n4.nabble.com/mailing-list-quot-reply-to-quot-td3067987.html > > > > See David Mercer's response. > > > > /M > > > > > > On 17 May 2011 13:50, Alexander Krasnukhin wrote: > > > >> I don't want to discuss this. Just wanted to ask why because it is unusual > >> these days. > >> > >> > >> On Tue, May 17, 2011 at 1:24 PM, Mazen Harake wrote: > >> > >>> This has been debated for as long as mailing lists have been used. This > >>> is a philosophical question. > >>> > >>> To shortcut the discussion which will probably develop now: Use "reply > >>> all". > >>> > >>> Everyone should learn this. The other way is simply a hack. > >>> > >>> See: http://www.metasystema.net/essays/reply-to.html > >>> > >>> /M > >>> > >>> > >>> On 17 May 2011 13:04, Alexander Krasnukhin wrote: > >>> > >>>> Hej, > >>>> > >>>> Why this mailing list doesn't add itself to the 'reply-to' header? I see > >>>> it isn't uncommon for subscribers to send message to the author directly > >>>> instead of the list. > >>>> > >>>> I wonder why? > >>>> > >>>> -- > >>>> Regards, > >>>> Alexander > >>>> > >>>> > >>>> _______________________________________________ > >>>> erlang-questions mailing list > >>>> erlang-questions@REDACTED > >>>> http://erlang.org/mailman/listinfo/erlang-questions > >>>> > >>>> > >>> > >> > >> > >> -- > >> Regards, > >> Alexander > >> > >> > > > > > -- > Regards, > Alexander > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From the.malkolm@REDACTED Tue May 17 17:07:50 2011 From: the.malkolm@REDACTED (Alexander Krasnukhin) Date: Tue, 17 May 2011 17:07:50 +0200 Subject: [erlang-questions] 'reply-to' header in this mailing list In-Reply-To: <20110517142848.GA9263@erix.ericsson.se> References: <20110517142848.GA9263@erix.ericsson.se> Message-ID: Yes, yes. I've got this. People from telecom will always rely on standards instead of people expectations. Good. Right. Understandable. On Tue, May 17, 2011 at 4:28 PM, Raimo Niskanen < raimo+erlang-questions@REDACTED> wrote: > Search the archives. Do not waste bandwidth. > > The same bottom line as the last time still applies: > http://erlang.org/pipermail/erlang-questions/2010-December/055017.html > > / Raimo Niskanen, mailing list maintainer at erlang dot org > > > > On Tue, May 17, 2011 at 02:03:18PM +0200, Alexander Krasnukhin wrote: > > Yeah, yeah. I've got this. It is some kind of local joke. Don't have > > anything to ask? Why not just ask why the hell "reply-to" isn't the > mailing > > list address itself? > > > > On Tue, May 17, 2011 at 1:58 PM, Mazen Harake >wrote: > > > > > > > > > http://erlang.2086793.n4.nabble.com/mailing-list-quot-reply-to-quot-td3067987.html > > > > > > See David Mercer's response. > > > > > > /M > > > > > > > > > On 17 May 2011 13:50, Alexander Krasnukhin > wrote: > > > > > >> I don't want to discuss this. Just wanted to ask why because it is > unusual > > >> these days. > > >> > > >> > > >> On Tue, May 17, 2011 at 1:24 PM, Mazen Harake >wrote: > > >> > > >>> This has been debated for as long as mailing lists have been used. > This > > >>> is a philosophical question. > > >>> > > >>> To shortcut the discussion which will probably develop now: Use > "reply > > >>> all". > > >>> > > >>> Everyone should learn this. The other way is simply a hack. > > >>> > > >>> See: http://www.metasystema.net/essays/reply-to.html > > >>> > > >>> /M > > >>> > > >>> > > >>> On 17 May 2011 13:04, Alexander Krasnukhin >wrote: > > >>> > > >>>> Hej, > > >>>> > > >>>> Why this mailing list doesn't add itself to the 'reply-to' header? I > see > > >>>> it isn't uncommon for subscribers to send message to the author > directly > > >>>> instead of the list. > > >>>> > > >>>> I wonder why? > > >>>> > > >>>> -- > > >>>> Regards, > > >>>> Alexander > > >>>> > > >>>> > > >>>> _______________________________________________ > > >>>> erlang-questions mailing list > > >>>> erlang-questions@REDACTED > > >>>> http://erlang.org/mailman/listinfo/erlang-questions > > >>>> > > >>>> > > >>> > > >> > > >> > > >> -- > > >> Regards, > > >> Alexander > > >> > > >> > > > > > > > > > -- > > Regards, > > Alexander > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > -- > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Regards, Alexander -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlsson.richard@REDACTED Tue May 17 18:04:26 2011 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Tue, 17 May 2011 18:04:26 +0200 Subject: [erlang-questions] Caching server In-Reply-To: References: Message-ID: <4DD29C8A.3070509@gmail.com> On 2011-02-19 03:19, Nicholas Wieland wrote: > Hi *, I'm reading the Manning book. My question is very simple: a > full chapter of the book is devoted to the implementation of a simple > caching server. The author, if I got it correctly, at one point > states that in Erlang, thanks to its lightweight processes, it's ok > to have a caching server that spawns a process for every key/value > pair. Of course I don't expect that the example in the book is a > production ready implementation, but I would like to ask if it would > be possible for an architecture like this to be production ready > (say, something like Redis), or if I should take it with a pinch of > salt, only as a demonstration. This thing made me curious because > there's no language or technology that would permit something like > this, hence my question :) > > TIA, This was also asked (and answered) in a thread on the Manning forums: http://www.manning-sandbox.com/thread.jspa?threadID=40749&tstart=0 As Martin said there, "this overall design has been used in production but the one used in production is a bit more complex. The current design [in the book] was specifically formulated to illustrate a number of design principles and Erlang features. It is really more for instructional purposes as opposed to direct production use." (If you read the thread, it might look as if Eric is contradicting Martin by saying "the cache has not been used or tested in production", but then Eric is referring to the implementation as it stands in the book.) In summary: yes, a similar design has actually been used in production. It's certainly an _easy_ way of implementing a cache, because it solves the storage and eviction issues by simply leveraging Erlang's processes and timeouts. However, processes are a finite resource: you'll need to set the upper limit with "erl -P..." if you want to be able to have more than the default maximum of 32768 processes. Whether this implementation is efficient enough for you depends on your use case. Measure and see. Processes don't magically solve all problems, even if it sometimes might look like it - there are always tradeoffs, in this case between ease of implementation on one hand and speed of access and memory overhead on the other. As a cache to avoid much more expensive network communication, and storing reasonably large chunks of data (like a web page) per key, its performance should be quite good. As a cache to avoid relatively quick disk operations with small data items for each key, it's not so good (but perhaps better than you might expect). /Richard From carlsson.richard@REDACTED Tue May 17 18:06:32 2011 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Tue, 17 May 2011 18:06:32 +0200 Subject: [erlang-questions] [erlang-questions 67] Problem using -(extends) with gen_server In-Reply-To: References: Message-ID: <4DD29D08.40201@gmail.com> On 03/28/2011 02:32 AM, Ken Robinson wrote: > Hi All, > I was trying to use -(extends) with gen_server. All the callback > methods remained the same. The only exported function from the > extended gen_server was the handle_call/3. What I found was it seemed > to be failing at the init stage. Does gen_server work with -(extends) > or should it be avoided. Does -(extends) only work with vanilla > modules? > The (still experimental) inheritance declaration -extends(foo) can be used both in plain modules and in parameterized modules. There's nothing special about gen_server - I just tried doing what you described, and it works. There are some things to consider, though: - You need to have the same #state{} record declaration in both modules, if you are going to override one or more callbacks to do anything that reads or modifies the server state. Hence, put that declaration in a header file. - If you override one of the handle_call/handle_cast/handle_info functions, you should probably provide a catch-all clause that manually delegates any messages that you're not matching to the corresponding function in the base module, like this: handle_call(..., From, State) -> ...; handle_call(Request, From, State) -> ?BASE_MODULE:handle_call(Request, From, State). (The BASE_MODULE macro is automatically defined when you use -extends.) If you do this, things should work, but you may want to think twice about what it is you're creating here, and if inheritance is the right way to go. You won't be able to change the state record in the base implementation without affecting all processes that inherit from it, and you should at least have an "extension" field in the state record from start that can hold a proplist or similar so that the extended servers have somewhere to put any additional state they need to add. /Richard From carlsson.richard@REDACTED Tue May 17 18:09:13 2011 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Tue, 17 May 2011 18:09:13 +0200 Subject: [erlang-questions] GPL3 - EPL compatibility In-Reply-To: References: Message-ID: <4DD29DA9.8090708@gmail.com> On 04/26/2011 06:40 PM, Roberto Majadas Lopez wrote: > 2011/4/26 Jesse Gumm > > > You're free to release a program under any license you want. The EPL > pertains to the Erlang language itself, not necessarily to programs > written in Erlang. The Erlang language itself is not licensed - anyone can make their own implementation if they want. The standard BEAM interpreter from OTP is published under EPL, but generallly, code running under an interpreter is just considered to be input and is not affected by the licensing (see e.g. http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL). Perhaps this is what Jesse meant. The standard library is another matter, however - see below. > > But if i use erlang crypto server or another one released under EPL . > can this relationship be considered dynamic link ? Yes, it can. See http://www.gnu.org/licenses/lgpl-java.html - the situation is the same for Erlang. You can't use GPL (any version) in combination with the Erlang standard libraries since they are published only under the EPL. The LGPL (2 or 3) can however be used. /Richard From ingela.andin@REDACTED Tue May 17 18:09:50 2011 From: ingela.andin@REDACTED (Ingela Andin) Date: Tue, 17 May 2011 18:09:50 +0200 Subject: [erlang-questions] mochiweb https/ssl In-Reply-To: References: <1304632965.1894.13.camel@sasa-laptop> Message-ID: Hi! I have investigated this and corrected a small bug when handling session invalidation that caused your occasional error printouts. But I think your main problem is that erlang ssl conforms to the standard and invalidates sessions when the peer closes a connection without sending a ssl protocol close notify message. However in TLS 1.1, failure to properly close a connection no longer requires that a session not be resumed. This is a change from TLS 1.0 to conform with widespread implementation practice. So we have decided to change erlang ssl to conform to widespread implementation practice. Regards Ingela Erlang/OTP team - Ericsson AB 2011/5/17 sasa : > Hello, > I spent last week fighting with SSL problems without success. Eventually I > switched to the stunnel based SSL which delegates to Erlang HTTP server. > Following are the characteristics of the behavior I experienced last week. > These are a bit different than the original ones, but I didn't want to open > new topic. I am posting this in case someone is stuck with the similar > behavior. > 1. The mochiweb http server runs without problems since the beginning of the > year. It also servers some small number of SSL users. The server is the same > erlang application running on the same node. > 2. Every day of the last week, in the morning, I would force the users to > use SSL (https) rather than http. > 3. The server then works fine for couple of hours. > 4. At one point, the servers starts responding very slowly. Restart of the > erlang application, node, or even the machine doesn't help. > 5. At the same time, the http server (which is the same application on the > same node) is working fine. > 6. Kernel tuning didn't help. > 7. I don't notice anything strange in erlang log or on the OS level. > 8. In my application log, it seems as if most connections are not even > established. The same thing is confirmed from netstat output. The number of > connections is smaller than expected. It looks as if new requests are queued > somewhere or some main accept/listen loop is processing them slowly. > 9. The CPU usage is low as well as the memory usage. > After forcing users back to http, the problems disappeared. The server could > then normally serve smaller number of SSL users. > It seems to me that the problem is somewhere in the mochiweb/erlang. After > switching to stunnel, which is in front of that same mochiweb application, > everything is working nicely. I should note that stunnel uses more CPU. > I am not quite sure why is it not working for me. I had load tests which > performed fine. Maybe the problem is that my real users are constantly > connecting/disconnecting, closing browsers during the request etc. I didn't > load test this type of users. > In any case, the behavior described above?occurred?every day, and was > resolved when switching to stunnel SSL. > I am sorry it didn't work out for me. I would be happier to use erlang SSL, > so I'll try again when the new version is released. > Regards, > Sasa > > On Fri, May 6, 2011 at 12:02 AM, sasa wrote: >> >> Hello, >> >> First of all, I apologize if this question occurs twice. I have tried >> submitting it couple of hours ago via google groups, but it didn't show up, >> so I'm trying via e-mail now. >> >> I am trying to develop https comet (long polling) server using mochiweb. I >> have already written one such http server which is in production for couple >> of months and serves no more than 1000 concurrent users, sending broadcast >> message to all concurrent users at an average rate of 0.3 broadcast/sec >> >> When I added ssl support, it essentially works when smaller number of >> users (about 100-200) are connected. With larger number, it stops responding >> correctly i.e. some connection attempts are refused, requests time out etc. >> Only ssl/https part seems to be affected by this behavior. >> >> To better test this, I developed small test mochiweb app which works as >> follows: >> 1. Spawn and register singleton broadcast process >> 2. For each request, the erlang process sends its pid to the broadcast >> process. Then it waits for the message from the broadcast process >> 3. Every 5 seconds broadcast process notifies all registered https >> response processes from 2, then it clears its list of registered processes >> 4. When process from 2 receives notification, it responds and finishes. >> >> In this test implementation, the response is hardcoded short string. For >> the sake of brevity, I didn't include the test app code, but if necessary I >> can do so. >> >> >> I then deployed this test app to the server, and set up two client >> machines to load test the server. The load testing code is also written in >> erlang, and is using ibrowse for making https requests, since I had some >> problems with httpc. The test client basically adheres to the protocol >> described above. It spawns request processes, with each process making the >> requests in an infinite loop. I gather success/failure stats in a singleton >> erlang process and print them out in regular intervals. >> >> As in the production system, with http, the test server performs >> correctly. With https, when number of concurrent requests reaches some >> treshold (about 1000), many requests are not served. >> >> On the client machine, I occasionally receive following errors: >> =ERROR REPORT==== >> ** State machine <0.17592.0> terminating >> >> ** Reason for termination = >> ** {badarg,[{erlang,byte_size,[undefined]}, >> ?????????? {ssl_tls1,split_secret,1}, >> ?????????? {ssl_tls1,prf,4}, >> ?????????? {ssl_handshake,master_secret,4}, >> ?????????? {ssl_connection,handle_resumed_session,2}, >> ?????????? {ssl_connection,next_state,3}, >> ?????????? {gen_fsm,handle_msg,7}, >> ?????????? {proc_lib,init_p_do_apply,3}]} >> >> >> While on the server I occasionally notice following errors: >> =SUPERVISOR REPORT==== 5-May-2011::11:06:33 === >> ??? Supervisor: {local,ssl_connection_sup} >> ??? Context:??? child_terminated >> ??? Reason:???? {{badmatch,{resumed,undefined}}, >> ???????????????? [{ssl_handshake,hello,4}, >> ????????????????? {ssl_connection,hello,2}, >> ????????????????? {ssl_connection,next_state,3}, >> ????????????????? {gen_fsm,handle_msg,7}, >> ????????????????? {proc_lib,init_p_do_apply,3}]} >> ??? Offender:?? [{pid,<0.7044.2>}, >> ???????????????? {name,undefined}, >> ???????????????? {mfargs,{ssl_connection,start_link,undefined}}, >> ???????????????? {restart_type,temporary}, >> ???????????????? {shutdown,4000}, >> ???????????????? {child_type,worker}] >> >> >> I have tried to tweak some OS parameters, as well as erlang parameters, >> but without success. After three days of experimenting, I am out of ideas >> and need some help or pointers. >> >> I am using Erlang R14B02 on 64 bit Ubuntu 10.04, all the machines are on >> the EC2 cloud. >> >> Following are sysctl.conf settings (I tried some more combinations without >> success): >> net.core.rmem_max = 16777216 >> net.core.wmem_max = 16777216 >> net.ipv4.tcp_rmem = 4096 87380 16777216 >> net.ipv4.tcp_wmem = 4096 65536 16777216 >> net.ipv4.tcp_syncookies = 1 >> >> net.ipv4.tcp_mem = 50576?? 64768?? 98152 >> net.core.netdev_max_backlog = 2500 >> net.ipv4.netfilter.ip_conntrack_max = 1048576 >> >> net.ipv4.ip_local_port_range = 1024 65535 >> >> net.ipv4.tcp_fin_timeout = 10 >> >> >> >> Following is ulimit -a output: >> core file size????????? (blocks, -c) 0 >> data seg size?????????? (kbytes, -d) unlimited >> scheduling priority???????????? (-e) 20 >> file size?????????????? (blocks, -f) unlimited >> pending signals???????????????? (-i) 16382 >> max locked memory?????? (kbytes, -l) 64 >> max memory size???????? (kbytes, -m) unlimited >> open files????????????????????? (-n) 32000 >> pipe size??????????? (512 bytes, -p) 8 >> POSIX message queues???? (bytes, -q) 819200 >> real-time priority????????????? (-r) 0 >> stack size????????????? (kbytes, -s) 8192 >> cpu time?????????????? (seconds, -t) unlimited >> max user processes????????????? (-u) unlimited >> virtual memory????????? (kbytes, -v) unlimited >> file locks????????????????????? (-x) unlimited >> >> >> >> These are mochiweb parameters: >> [ >> ? {port, 9999}, >> ? {name, https_test}, >> ? {ssl, true}, >> ? {ssl_opts, [ >> ??? {cacertfile, "keys/cacert.pem"}, >> ??? {certfile, "keys/cert.pem"}, >> ??? {keyfile, "keys/cert.key"}, >> ??? {depth, 0} >> ? ]} >> ] >> >> >> To use it on a 443 port, I have set up iptables port forwarding >> iptables -t nat -I PREROUTING --source 0/0 --destination 0/0 -p tcp >> --dport 443 -j REDIRECT --to-ports 9999 >> >> >> These are erl parameters: >> erl -P 268435456 -env ERL_MAX_PORTS 100000 >> >> >> >> If anybody has any idea, I would be most grateful. >> >> >> Best regards, >> Sasa > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > From carlsson.richard@REDACTED Tue May 17 18:12:05 2011 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Tue, 17 May 2011 18:12:05 +0200 Subject: [erlang-questions] What's the best way of producing bitmaps/pixelmaps through Erlang. In-Reply-To: References: <39be0c60-0105-4b1e-bda3-e197325f0edb@e35g2000yqc.googlegroups.com> <20110507175631.GB305@h216-235-12-168.host.egate.net> Message-ID: <4DD29E55.20401@gmail.com> On 05/07/2011 09:39 PM, G.S. wrote: > Thanks, I will check both. > > By the way, the purpose of use is creating Fractal Art. > > Regards, > -Gene If you just want to get started as quickly as possible, you could write to PPM format ASCII text files (http://en.wikipedia.org/wiki/Netpbm_format) and then use pnmtotiff, pnmtojpeg, etc. (see http://netpbm.sourceforge.net/) to convert them to the format you prefer. The ASCII representation makes it easy to look at the output while you're debugging, so that right now you can focus on generating graphics rather than getting the output format right. Some tools, such as GIMP, can read/write PPM files directly, if you want to quickly view the result. /Richard From vinoski@REDACTED Tue May 17 19:10:16 2011 From: vinoski@REDACTED (Steve Vinoski) Date: Tue, 17 May 2011 13:10:16 -0400 Subject: [erlang-questions] Caching server In-Reply-To: <4DD29C8A.3070509@gmail.com> References: <4DD29C8A.3070509@gmail.com> Message-ID: On Tue, May 17, 2011 at 12:04 PM, Richard Carlsson wrote: > > Processes don't magically solve all problems, even if it sometimes might > look like it - there are always tradeoffs, in this case between ease of > implementation on one hand and speed of access and memory overhead on the > other. As a cache to avoid much more expensive network communication, and > storing reasonably large chunks of data (like a web page) per key, its > performance should be quite good. As a cache to avoid relatively quick disk > operations with small data items for each key, it's not so good (but perhaps > better than you might expect). I can speak from experience that a process per cache entry works well if your cache hits are reasonably balanced across all entries. But for very popular cache entries, such as for popular web pages or web content, using a process per cache entry can negatively affect performance under load. Assuming the web server can handle thousands of concurrent client requests, the process per cache entry approach becomes a bottleneck if the majority of those clients are all requesting the same page or small set of pages, due to the serialization of the requests from all those concurrent connections into just one or a few cache process message queues. I wrote about this issue recently in Internet Computing: http://steve.vinoski.net/pdf/IC-Erlang_Web_Process_Bottlenecks.pdf Depending on what you're caching, one alternative is to just use an ets table instead, as the read concurrency is quite good and eviction is simple. Or, take a look at Redis or other such approaches. --steve From erlang@REDACTED Tue May 17 20:28:23 2011 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 17 May 2011 20:28:23 +0200 Subject: [erlang-questions] GPL3 - EPL compatibility In-Reply-To: <4DD29DA9.8090708@gmail.com> References: <4DD29DA9.8090708@gmail.com> Message-ID: On Tue, May 17, 2011 at 6:09 PM, Richard Carlsson < carlsson.richard@REDACTED> wrote: > On 04/26/2011 06:40 PM, Roberto Majadas Lopez wrote: > >> 2011/4/26 Jesse Gumm > >> >> >> You're free to release a program under any license you want. The EPL >> pertains to the Erlang language itself, not necessarily to programs >> written in Erlang. >> > > The Erlang language itself is not licensed - anyone can make their own > implementation if they want. If memory serves me well this is not quite true. Erlang is (or at least was) registered as a trademark in many countries. You are free to make your own implementation but not call it Erlang. The thinking behind this was to try and stop people making a language that was called Erlang but that did not have Erlang semantics, they would have to use a different name - this is a completely separate issue to the licensing issue. This was done years ago before open source became open and was still closed - I have no idea if this still applies today. If you want to make your own Erlang feel free, but give it a new name like iErlang for example... Observant folks will have noticed that Microsoft and others are suing Apple over trademarking claims to the string "App Store" /Joe > The standard BEAM interpreter from OTP is published under EPL, but > generallly, code running under an interpreter is just considered to be input > and is not affected by the licensing (see e.g. > http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL). Perhaps this > is what Jesse meant. The standard library is another matter, however - see > below. > > > >> But if i use erlang crypto server or another one released under EPL . >> can this relationship be considered dynamic link ? >> > > Yes, it can. See http://www.gnu.org/licenses/lgpl-java.html - the > situation is the same for Erlang. You can't use GPL (any version) in > combination with the Erlang standard libraries since they are published only > under the EPL. The LGPL (2 or 3) can however be used. > > /Richard > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hynek@REDACTED Tue May 17 21:53:44 2011 From: hynek@REDACTED (Hynek Vychodil) Date: Tue, 17 May 2011 21:53:44 +0200 Subject: [erlang-questions] opaque type definition makes dialyzer unhappy even in same module In-Reply-To: References: Message-ID: The issue with tagging in this case is that it makes it will perform worse. The code where this warning occurred I work with internal structures. But it would be possible make some sort of internal subtype without tag. Anyway I think that problems comes from interaction with array module which doesn't preserve item type. But I think the issue with opaque type is more likely bug. Dialyzer should not complain about opacity violation for type defined in same module. Anyway i'm trying pairing heap now which seems fits to erlang functional nature better and also performs significantly better. BTW Is there any way to suppress dialyzer warning by some sort of annotation? For example perlcritic supports suppressing of known but intentional violations by special comments. On Tue, May 17, 2011 at 1:30 PM, Jamie Brandon wrote: > I ran into the same problem a few days ago. Dialyzer doesn't like > opaque types which are simple aliases. if you add a tag (and modify > the rest of the code accordingly) it should work fine: > > -type fib_heap() :: {fib_heap, [fib_heap_node()]}. > > This will also make debugging easier if fib_heap shows up in an error report. > > On 16 May 2011 04:16, Hynek Vychodil wrote: >> Hi, >> >> I'm playing with dialyzer in mine attempt to fibonacci heap >> implementation and I got weird behavior. When I define fib_heap() as >> type dialyzer seems happy but when I change it to -opaque it produce >> warnings below >> >> $ dialyzer fib_heap.erl >> ?Checking whether the PLT /home/hynek/.dialyzer_plt is up-to-date... yes >> ?Proceeding with analysis... >> fib_heap.erl:32: The call fib_heap:reset_min_(H::[any()]) does not >> have an opaque term of type fib_heap:fib_heap() as 1st argument >> fib_heap.erl:46: The call fib_heap:reset_min_(T::[any()],H::any(),[]) >> does not have opaque terms as 1st and 3rd arguments >> fib_heap.erl:53: The call >> fib_heap:reset_min_(T::[any()],H::{_,_},[any(),...]) does not have >> opaque terms as 1st and 3rd arguments >> fib_heap.erl:55: The call >> fib_heap:reset_min_(T::[any()],Min::any(),[any(),...]) does not have >> opaque terms as 1st and 3rd arguments >> fib_heap.erl:64: The call >> fib_heap:compact_(nonempty_maybe_improper_list(),array()) does not >> have an opaque term of type fib_heap:fib_heap() as 1st argument >> ?done in 0m0.72s >> done (warnings were emitted) >> >> What is going on? According to documentation: "Types declared as >> opaque represent sets of terms whose structure is not supposed to be >> visible in any way outside of their defining module (i.e., only the >> module defining them is allowed to depend on their term structure)." I >> only changed '-type' to '-opaque' on line 8, I stay in same module but >> dialyzer emits warnings which I don't understand and don't know how I >> should fix or suppress. >> >> -- >> --Hynek (Pichi) Vychodil >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -- --Hynek (Pichi) Vychodil Analyze your data in minutes. Share your insights instantly. Thrill your boss.? Be a data hero! Try GoodData now for free: www.gooddata.com From ok@REDACTED Wed May 18 00:33:37 2011 From: ok@REDACTED (Richard O'Keefe) Date: Wed, 18 May 2011 10:33:37 +1200 Subject: [erlang-questions] [Erlang]about "apply" function in the erlang.erl In-Reply-To: References: Message-ID: <045CFCB2-CF73-40F6-805F-2AC5E6E2CF5A@cs.otago.ac.nz> On 17/05/2011, at 7:48 PM, ??? wrote: > hi, > I see "apply" function invoke "apply?function in the "erlang.erl". > I can`t understand it. > Who can explain for me? Thanks. > > 57 apply(Fun, Args) -> > 58 apply(Fun, Args). > 59 > 60 apply(Mod, Name, Args) -> > 61 apply(Mod, Name, Args). It's a fairly common "bootstrapping" sort of thing. Presumably - when the compiler sees apply/2 or apply/3 in an expression it generates special in-line code - there needs to be a "real" function definition so that it can be called indirectly itself, discoverable in the module exports, traced if calls arrive that way in the debugger, &c From roberto@REDACTED Wed May 18 00:37:02 2011 From: roberto@REDACTED (Roberto Ostinelli) Date: Wed, 18 May 2011 00:37:02 +0200 Subject: [erlang-questions] supervisor children's pid Message-ID: dear list, i'm starting three anonymous gen_server from a supervisor. i need every gen_server to know the pid of the other two. currently, i'm calling supervisor:which_children/1 on the init function of the gen_servers, and match the Ids to get the Child [Pid]. is this the best strategy to achieve this? thank you, r. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Wed May 18 01:45:25 2011 From: ok@REDACTED (Richard O'Keefe) Date: Wed, 18 May 2011 11:45:25 +1200 Subject: [erlang-questions] 'reply-to' header in this mailing list In-Reply-To: References: <20110517142848.GA9263@erix.ericsson.se> Message-ID: <230D6DBF-EE90-475F-A973-DF0E7B71EF19@cs.otago.ac.nz> On 18/05/2011, at 3:07 AM, Alexander Krasnukhin wrote: > Yes, yes. I've got this. People from telecom will always rely on standards instead of people expectations. Good. Right. Understandable. That sounds a bit sarcastic. The thing is that the Erlang mailing list behaves *EXACTLY* the way I expect a mailing list to work. I expect "Reply All" to reply to everyone on the list. I expect "Reply" to go just to the author. I expect it to work the way mailing lists always used to work. The standard in this case is not arbitrary, but part of a coherent design to ensure a straightforward user experience. From t.greenwoodgeer@REDACTED Wed May 18 02:25:35 2011 From: t.greenwoodgeer@REDACTED (Todd) Date: Tue, 17 May 2011 17:25:35 -0700 Subject: [erlang-questions] What are the "Most valuable libraries?"...and a few other questions In-Reply-To: <230D6DBF-EE90-475F-A973-DF0E7B71EF19@cs.otago.ac.nz> References: <20110517142848.GA9263@erix.ericsson.se> <230D6DBF-EE90-475F-A973-DF0E7B71EF19@cs.otago.ac.nz> Message-ID: <4DD311FF.2090402@gmail.com> The whole "reply-all" debate has stirred me to ask some festering questions... 1. In general, what are the most valuable libraries to learn, both within the Erlang dist and external? 2. Is there a consolidated/curated repository of libraries that is industry standard? I know the erlware folks have a repo...is that both a complete and accepted authoritative repo? From reading the list, it sounds like there's also a fair bit of stuff scattered about in github, too. 3. How does one easily multithread an app? For instance, there's pmap in clojure and something similar in akka that lets you map a function across a list, and it allocates threads accordingly... literally something like: "pmap(myfun, mylist);" 4. Along that note, does anyone have any ideas as to how to tackle the Typesafe 'getting started tutorial?' http://typesafe.com/resources/getting-started/tutorials/getting-started-first-scala.html (Typesafe is the funded version of Jonas Bon?r's Akka combined with Scala) 4b. Side note: is anyone concerned about Akka/Typesafe stealing mindshare? And lastly, the most burning of questions: 5. How does one push an app such that it self instantiates it's processes across the cluster? I can see how OTP is great at managing an app on a single node, but how do you say something like: "create one of these processes on each node in the cluster, and restart 1-for-1 if they die"... or something similar. I see mention of gproc, but honestly, I don't see how to use it. Likewise, if nodes are added to the cluster, how would you ensure that the necessary processes are pushed to the new node after it joins the cluster? 6. How do you deploy and live code upgrade in real life? I've been looking at some of the work by the 'Dukes of Erl' ... is erlrc what folks commononly use? Dukes of Erl project (Paul Mineiro): https://code.google.com/p/erlrc/ Paul Mineiro's Erlang factory 2009 presentation: http://www.erlang-factory.com/conference/SFBayAreaErlangFactory2009/speakers/PaulMineiro 7. Does anyone use dynamic load balancing of demand across a cluster (e.g. spinning up erlang processes to meet the demand curve?) 8. What's the best way to integrate w/ other code bases. In akka, you'd use camel as an integration bus. What are the common ways to integrate with erlang? Is that what ports and nifs are for? Forgive my ignorance, but I always considered those as simply ways to write code in a different, perhaps more comfortable language...not as integration mechanisms. Also, I've continued to peck away at various newbie tutorials. Any comments/suggestions/corrections are welcome. https://github.com/ToddG/experimental/tree/master/erlang/wilderness -Todd From sigmastar@REDACTED Wed May 18 02:39:49 2011 From: sigmastar@REDACTED (Jesse Gumm) Date: Tue, 17 May 2011 19:39:49 -0500 Subject: [erlang-questions] GPL3 - EPL compatibility In-Reply-To: <4DD29DA9.8090708@gmail.com> References: <4DD29DA9.8090708@gmail.com> Message-ID: On Tue, May 17, 2011 at 11:09 AM, Richard Carlsson wrote: > but generallly, code running under an interpreter is > just considered to be input and is not affected by the licensing (see e.g. > http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL). Perhaps this > is what Jesse meant. You are correct, that is what I meant. Code you write is yours, regardless of the language it's written in. An .erl file you write is yours to release as you will, with the license of your choise, even if it interacts with code or libraries that you didn't write. That's not to say you can re-release someone else's code (ie the Erlang VM or its libraries) under whatever license you want. And the OP sounds like he just wants to write his own stuff and distribute it on github or whatever. There are no problems there in doing so. -Jesse -- Jesse Gumm Sigma Star Systems 414.940.4866 gumm@REDACTED http://www.sigma-star.com From moxford@REDACTED Wed May 18 02:41:19 2011 From: moxford@REDACTED (Mike Oxford) Date: Tue, 17 May 2011 17:41:19 -0700 Subject: [erlang-questions] What are the "Most valuable libraries?"...and a few other questions In-Reply-To: <4DD311FF.2090402@gmail.com> References: <20110517142848.GA9263@erix.ericsson.se> <230D6DBF-EE90-475F-A973-DF0E7B71EF19@cs.otago.ac.nz> <4DD311FF.2090402@gmail.com> Message-ID: On Tue, May 17, 2011 at 5:25 PM, Todd wrote: > The whole "reply-all" debate has stirred me to ask some festering > questions... > > 1. In general, what are the most valuable libraries to learn, both within > the Erlang dist and external? > OTP, gproc to start > > 2. Is there a consolidated/curated repository of libraries that is industry > standard? I know the erlware folks have a repo...is that both a complete and > accepted authoritative repo? From reading the list, it sounds like there's > also a fair bit of stuff scattered about in github, too. > OTP is the industry standard > 3. How does one easily multithread an app? For instance, there's pmap in > clojure and something similar in akka that lets you map a function across a > list, and it allocates threads accordingly... > You spawn more processes. Erlang handles the SMP portion for you. There is some parallelization stuff available for Erlang as well, or roll your own. http://99-bottles-of-beer.net/language-erlang-1482.html > > 4. Along that note, does anyone have any ideas as to how to tackle the > Typesafe 'getting started tutorial?' > http://learnyousomeerlang.com/ > 4b. Side note: is anyone concerned about Akka/Typesafe stealing mindshare? > Dif'rnt stroke fer dif'rnt folks. > 5. How does one push an app such that it self instantiates it's processes > across the cluster? I can see how OTP is great at managing an app on a > single node, but how do you say something like: "create one of these > processes on each node in the cluster, and restart 1-for-1 if they die"... > or something similar. I see mention of gproc, but honestly, I don't see how > to use it. Likewise, if nodes are added to the cluster, how would you ensure > that the necessary processes are pushed to the new node after it joins the > cluster? > Use spawn_link/2 spawn_link(Node, Fun) -> pid() If you have the Pid for your remote supervisor you can just use supervisor:start_link and give it the remote Pid, or Pid ! it. > 6. How do you deploy and live code upgrade in real life? I've been looking > at some of the work by the 'Dukes of Erl' ... is erlrc what folks commononly > use? > > No idea, I haven't gotten that far yet. :) > 7. Does anyone use dynamic load balancing of demand across a cluster (e.g. > spinning up erlang processes to meet the demand curve?) > We do, to some extent. We start with a pool and if we exceed that we go dynamic. Might be better to just go dynamic and save the shared-state munging.... > 8. What's the best way to integrate w/ other code bases. In akka, you'd use > camel as an integration bus. What are the common ways to integrate with > erlang? Is that what ports and nifs are for? Forgive my ignorance, but I > always considered those as simply ways to write code in a different, perhaps > more comfortable language...not as integration mechanisms. > Ports and NIFs, yes. Whether the integration is for performance, functionality or preferences it's all the same: something external. Also, I've continued to peck away at various newbie tutorials. Any > comments/suggestions/corrections are welcome. > See #4. G'luck! -mox -------------- next part -------------- An HTML attachment was scrubbed... URL: From fred.hebert@REDACTED Wed May 18 02:59:21 2011 From: fred.hebert@REDACTED (=?iso-8859-1?Q?Fr=E9d=E9ric_Trottier-H=E9bert?=) Date: Tue, 17 May 2011 20:59:21 -0400 Subject: [erlang-questions] What are the "Most valuable libraries?"...and a few other questions In-Reply-To: <4DD311FF.2090402@gmail.com> References: <20110517142848.GA9263@erix.ericsson.se> <230D6DBF-EE90-475F-A973-DF0E7B71EF19@cs.otago.ac.nz> <4DD311FF.2090402@gmail.com> Message-ID: On 2011-05-17, at 20:25 PM, Todd wrote: > The whole "reply-all" debate has stirred me to ask some festering questions... > > 1. In general, what are the most valuable libraries to learn, both within the Erlang dist and external? > In my opinion, learning the OTP behaviour modules brought me a lot in term of Erlang programming efficiency, and also taught me a lot in terms of writing abstractions. They're pretty useful regarding that. Add the sys module to the mix; it's pretty good as far as being able to debug gen_* behaviour goes. For external libraries, I'd say gproc, ibrowse, proper and meck are pretty neat. The riak_core stuff is also impressive. > 2. Is there a consolidated/curated repository of libraries that is industry standard? I know the erlware folks have a repo...is that both a complete and accepted authoritative repo? From reading the list, it sounds like there's also a fair bit of stuff scattered about in github, too. > Not really. You have erlware, as you mentioned, but I personally tend to use agner (http://erlagner.org/). > 3. How does one easily multithread an app? For instance, there's pmap in clojure and something similar in akka that lets you map a function across a list, and it allocates threads accordingly... > > literally something like: "pmap(myfun, mylist);" In my own use cases, I tend to write Erlang for multi-user stuff, server-side software. In these cases, parallelism on things like mapping over a list is rather useless. By this, I mean that if you only map over one list at a time, then breaking it in N processes might win you some time (assuming the function you apply takes more time to run than spawning and communicating data), but if you have N lists for N users each having their own process, then the system is already processes a lot of data in parallel, probably more than what could be useful if you had M processes per list on top of the N users -- at this point you get to play with the scheduler and processes might fight for CPU time. This is pretty complex but my point is that if you're writing server software where concurrency units are already large, but there are many of them, low-level parallelism as in a pmap function isn't the most useful enhancement. Smart application architecture design might play a lot more in the long run. In any case, if you really want a pmap, there's rpc:pmap/3 (http://erldocs.com/R14B02/kernel/rpc.html?i=0&search=pmap#pmap/4) and conc lists (http://dustin.github.com/2010/03/04/erlang-conc.html, also on agner). Measure and see what fits. > > 4. Along that note, does anyone have any ideas as to how to tackle the Typesafe 'getting started tutorial?' > > http://typesafe.com/resources/getting-started/tutorials/getting-started-first-scala.html > > (Typesafe is the funded version of Jonas Bon?r's Akka combined with Scala) This is a tough one. There are plenty of guides to get started with Erlang. You have 2-3 versions of them in the official documentation, there are screencasts over at pragmatic programmers, I write http://learnyousomeerlang.com and you have plenty of blog posts around the web doing a good, short job of introducing users to the language. The latest one doing that is from IBM (http://www.ibm.com/developerworks/xml/library/os-erlang1/index.html?ca=drs-) For the part about getting an executable running fast, things in Erlang are a bit complex. The standard way to get an application running has to do with OTP Applications and OTP Releases; this is complex, requires you to learn the whole framework and can't be explained fast. You could probably do something basic with erl -run and -noshell options, but I'd also like to see one or two tutorials focusing on Escripts as a quick jumpstart option. > > 4b. Side note: is anyone concerned about Akka/Typesafe stealing mindshare? Not really. I don't think many established Erlangers are going to leave for Scala/Akka. I think many Java people who were somewhat interested but hesitating about Erlang might study Scala/Akka first. If they like it, I wouldn't be surprised to see them trying Erlang at some point, given Akka is heavily inspired by its design choices. The more languages try to borrow Erlang idioms, the better (although I'd like it if they focused more on fault-tolerance) > > And lastly, the most burning of questions: > > 5. How does one push an app such that it self instantiates it's processes across the cluster? I can see how OTP is great at managing an app on a single node, but how do you say something like: "create one of these processes on each node in the cluster, and restart 1-for-1 if they die"... or something similar. I see mention of gproc, but honestly, I don't see how to use it. Likewise, if nodes are added to the cluster, how would you ensure that the necessary processes are pushed to the new node after it joins the cluster? You can have many design options. Using OTP applications, you can specify a takeover/failover mechanism, but not something that would be instantly started on all nodes. To do something like that, the simplest thing I can think of is to simply start your application on each node. You could add some kind of 'sync' function to ask each node to synchronises itself with the rest of the cluster (this is what the global module does as far as I know) or try to work some mechanism that does it automatically. Generally, distributed applications where they all run at the same time and need to share some state is a harder problem than just having independent components distributed across a cluster. Things will be very application specific. Is the state shared or independent? Can one of the nodes disappear without impacting the rest of the application? What do you do in cases of netsplits when you can't know if a node is down or the connection broken? There are many questions like this that will drive your design. You can possibly look at riak_core for some design decisions, then at the global module for an entirely different (and smaller scale) approach. > > 6. How do you deploy and live code upgrade in real life? I've been looking at some of the work by the 'Dukes of Erl' ... is erlrc what folks commononly use? > > Dukes of Erl project (Paul Mineiro): > https://code.google.com/p/erlrc/ > > Paul Mineiro's Erlang factory 2009 presentation: > http://www.erlang-factory.com/conference/SFBayAreaErlangFactory2009/speakers/PaulMineiro Releases have mechanisms in place to handle this. The basic idea is that every gen_* behaviour implements callbacks from the sys module. These callbacks allow various operations such as suspending a behaviour (switching it into a 'I only accept sys messages' mode), calling for the code change functions, then resuming it. This generally allows safe code updates, but always remember to test things before deploying them (and test the deploying itself). > > 7. Does anyone use dynamic load balancing of demand across a cluster (e.g. spinning up erlang processes to meet the demand curve?) > I'll leave this to be answered by people with more production experience than I have, but I generally write my programs so that each concurrent (independent) unit of computation has its own process. By this I mean that in the case of a web server, I'll usually create one process per query rather than one process for the data fetching, then one for the templating, etc. Some things are sequential and should remain that way in the code. The VM also does a lot of heavy lifting for me with regards to that approach, distributing processes in ways that makes things reasonably balanced. > 8. What's the best way to integrate w/ other code bases. In akka, you'd use camel as an integration bus. What are the common ways to integrate with erlang? Is that what ports and nifs are for? Forgive my ignorance, but I always considered those as simply ways to write code in a different, perhaps more comfortable language...not as integration mechanisms. Ports, Port Drivers, C Nodes and NIFs are all standard ways to communicate with the outside world. There are also interfaces to Java and communication layers to PHP, Ruby, Python, etc. You can also add BERT-RPC as a protocol that can be used with Erlang, among others. > > Also, I've continued to peck away at various newbie tutorials. Any comments/suggestions/corrections are welcome. > > https://github.com/ToddG/experimental/tree/master/erlang/wilderness > > -Todd > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions Hopefully, this is helpful :) -- Fred H?bert http://www.erlang-solutions.com From yaohui1984@REDACTED Wed May 18 03:32:09 2011 From: yaohui1984@REDACTED (=?ISO-8859-1?B?eWFvaHVp?=) Date: Wed, 18 May 2011 09:32:09 +0800 Subject: [erlang-questions] About error enfile? Message-ID: A test again ,but still error i changed to /proc/sys/fs/file-max 8388608 and ulimit -n 1000000 cat /proc/net/sockstat sockets: used 525173 TCP: inuse 525104 orphan 0 tw 0 alloc 525104 mem 517029 UDP: inuse 0 mem 0 UDPLITE: inuse 0 RAW: inuse 0 FRAG: inuse 0 memory 0 cat /proc/sys/fs/file-nr 525632 0 8388608 =ERROR REPORT==== 18-May-2011::08:52:26 === Error in process <0.34.0> with exit value: {{badmatch,{error,enfile}},[{server,do_accept,1}]} dmesg out of socket memory apper out of socket memory says something. I think you can keep watching /proc/sys/fs/file-nr and /proc/net/sockstat during test. On Tue, May 17, 2011 at 2:40 PM, yaohui wrote: /proc/sys/fs/file-nr "416 0 4821388" is right now, I'll do a test again while observing this parameter dmesg print a lot log out of socket memory Can you post the output of "dmesg" which might include some OS warning messages. "416 0 4821388" is some time after this happened, right? It shows that there aren't many files open. Andy On Tue, May 17, 2011 at 2:32 PM, yaohui wrote: It's a problem 800000 < 1000K, but connections are less than 540k cat /proc/sys/fs/file-nr result 416 0 4821388 ulimit -n 800000? 800000 < 1000K. Is this the problem? What about cat /proc/sys/fs/file-nr? On Tue, May 17, 2011 at 9:38 AM, yaohui wrote: I do a test C1000k, when connections reach to 540k, I got a error {badmatch,{error,enfile}}. {error,enfile} this error represents the files tables is full (for the entire OS) but my kernel ulimit -n 800000 cat /proc/sys/fs/file-max 2215800 {error,enfile} is this error means other problem? _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared@REDACTED Wed May 18 04:50:05 2011 From: jared@REDACTED (Jared Morrow) Date: Tue, 17 May 2011 20:50:05 -0600 Subject: [erlang-questions] What are the "Most valuable libraries?"...and a few other questions In-Reply-To: <4DD311FF.2090402@gmail.com> References: <20110517142848.GA9263@erix.ericsson.se> <230D6DBF-EE90-475F-A973-DF0E7B71EF19@cs.otago.ac.nz> <4DD311FF.2090402@gmail.com> Message-ID: > > > > 5. How does one push an app such that it self instantiates it's processes > across the cluster? I can see how OTP is great at managing an app on a > single node, but how do you say something like: "create one of these > processes on each node in the cluster, and restart 1-for-1 if they die"... > or something similar. I see mention of gproc, but honestly, I don't see how > to use it. Likewise, if nodes are added to the cluster, how would you ensure > that the necessary processes are pushed to the new node after it joins the > cluster? > > 6. How do you deploy and live code upgrade in real life? I've been looking > at some of the work by the 'Dukes of Erl' ... is erlrc what folks commononly > use? > Lots of folks do it different ways. Two good talks that will aid you in deployment are Dizzy Smith's talk about rebar and Joe Williams talk about deployment and hot code upgrades, both at EF San Fran 2011. Dizzy: http://www.erlang-factory.com/conference/SFBay2011/speakers/DizzySmith Joe: http://www.erlang-factory.com/conference/SFBay2011/speakers/JoeWilliams > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From langxianzhe@REDACTED Wed May 18 05:43:16 2011 From: langxianzhe@REDACTED (jasonlxw) Date: Tue, 17 May 2011 20:43:16 -0700 (PDT) Subject: [erlang-questions] [Erlang]about "apply" function in the erlang.erl In-Reply-To: <1305618696.4854.9.camel@seasc1137> References: <1305618696.4854.9.camel@seasc1137> Message-ID: <1305690196832-3531504.post@n4.nabble.com> >From erlang/doc: By convention, most built-in functions (BIFs) are seen as being in the module erlang. hi bengt.kleberg Is that the 'apply/2' is invoked by the erlang:apply/2 in the 'erlang.erl' implemented in C, not Erlang? thanks! jason ----- Never give up -- View this message in context: http://erlang.2086793.n4.nabble.com/Erlang-about-apply-function-in-the-erlang-erl-tp3528347p3531504.html Sent from the Erlang Questions mailing list archive at Nabble.com. From vances@REDACTED Wed May 18 06:48:25 2011 From: vances@REDACTED (Vance Shipley) Date: Wed, 18 May 2011 10:18:25 +0530 Subject: [erlang-questions] supervisor children's pid In-Reply-To: References: Message-ID: <20110518044824.GC7320@aluminum.local> On Wed, May 18, 2011 at 12:37:02AM +0200, Roberto Ostinelli wrote: } currently, i'm calling supervisor:which_children/1 on the init function of } the gen_servers, and match the Ids to get the Child [Pid]. You can't call the supervisor from the init function of one of it's own children. You have to return from init/1 before that is possible. What you can do is to return {ok, State, Timeout} from init/1 with a Timeout value of 0 and go on with the initialization after the supervisor has completed starting the children. The attached example uses a psuedo state to carry on with the initialization: 1> supervisor:start_link(which_sup, []). Server=1, Siblings=[<0.36.0>,<0.35.0>] Server=2, Siblings=[<0.36.0>,<0.34.0>] Server=3, Siblings=[<0.35.0>,<0.34.0>] {ok,<0.33.0>} } is this the best strategy to achieve this? Yes, use supervisor:which_children/1 to learn the siblings. -- -Vance -------------- next part -------------- -module(which_sup). -behaviour(supervisor). -export([init/1]). init(_Args) -> ChildSpecs = [server_spec(N) || N <- lists:seq(1, 3)], {ok, {{one_for_one, 10, 60}, ChildSpecs}}. server_spec(N) -> StartMod = which_server, StartFunc = {gen_server, start_link, [StartMod, [self(), N], []]}, {N, StartFunc, permanent, 4000, worker, [StartMod]}. -------------- next part -------------- -module(which_server). -behaviour(gen_server). -export([init/1, handle_call/3, handle_cast/2, handle_info/2, terminate/2, code_change/3]). -record(state, {state, sup, siblings, n}). init([Sup, N]) -> process_flag(trap_exit, true), {ok, #state{sup = Sup, state = init, n = N}, 0}. handle_call(_Request, _From, State) -> {reply, ok, State}. handle_cast(_Request, State) -> {noreply, State}. handle_info(timeout, #state{sup = Sup, state = init, n = N} = State) -> Children = supervisor:which_children(Sup), SiblingSpecs = lists:keydelete(self(), 2, Children), Siblings = [Pid || {_, Pid, _, _} <- SiblingSpecs], io:fwrite("Server=~b, Siblings=~p~n", [N, Siblings]), {noreply, State#state{state = run, siblings = Siblings}}; handle_info(_Init, State) -> {noreply, State}. terminate(_Reason, _State) -> ok. code_change(_OldVsn, State, _Extra) -> {ok, State}. From michael.eugene.turner@REDACTED Wed May 18 07:35:52 2011 From: michael.eugene.turner@REDACTED (Michael Turner) Date: Wed, 18 May 2011 14:35:52 +0900 Subject: [erlang-questions] 'reply-to' header in this mailing list In-Reply-To: <230D6DBF-EE90-475F-A973-DF0E7B71EF19@cs.otago.ac.nz> References: <20110517142848.GA9263@erix.ericsson.se> <230D6DBF-EE90-475F-A973-DF0E7B71EF19@cs.otago.ac.nz> Message-ID: Does anyone have any statistics on this question? That is, what percentage of mailing lists "do it wrong"? It's counterintuitive to me that a "reply" on this mailing list is only to the individual. "Reply" is "Reply to the list" on every other mailing list I'm currently on, and on almost every mailing list I can remember being on. But perhaps my lifetime mailing list membership doesn't approach statistical significance. Although it may get me accused of "blindly following the herd," let me assert it anyway: arguments from "intuition" in commonly used software interfaces only work when you have statistically significant user support for them, not some purely formal, rule-based argument for your *personal* intuition. What's "intuitive" to one person may be counterintuitive to many. As pointed out long ago, "intuitive equals familiar": http://www.asktog.com/papers/raskinintuit.html And, as pointed out even longer ago, "a foolish consistency is the hobgoblin of small minds." (Emerson.) Perhaps to some people, a mailing list is like a noticeboard in a mostly-empty hallway. My mental model of a mailing list corresponds more closely to a conversation in a classroom. When you reply to an open question or comment in such a context, you cannot help but be heard by more than one person; most likely you'll be heard by everyone in the room. You actually have to make a special effort (i.e., lean over and whisper in an ear, or pass a note) to be sure that your reply is private. I think this corresponds pretty closely to the intuition of the average mailing list user. But erlangeurs may be different, I don't know. -michael turner On Wed, May 18, 2011 at 8:45 AM, Richard O'Keefe wrote: > > On 18/05/2011, at 3:07 AM, Alexander Krasnukhin wrote: > > > Yes, yes. I've got this. People from telecom will always rely on > standards instead of people expectations. Good. Right. Understandable. > > That sounds a bit sarcastic. > The thing is that the Erlang mailing list behaves *EXACTLY* the way I > expect > a mailing list to work. > I expect "Reply All" to reply to everyone on the list. > I expect "Reply" to go just to the author. > I expect it to work the way mailing lists always used to work. > > The standard in this case is not arbitrary, but part of a coherent > design to ensure a straightforward user experience. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thatpythonguy@REDACTED Wed May 18 08:04:02 2011 From: thatpythonguy@REDACTED (Ahmed Al-Saadi) Date: Wed, 18 May 2011 02:04:02 -0400 Subject: [erlang-questions] Erlangers in Montreal? In-Reply-To: <1305432181256-3523815.post@n4.nabble.com> References: <4D83B9A3.9050801@gmail.com> <1305432181256-3523815.post@n4.nabble.com> Message-ID: <4DD36152.9030508@gmail.com> Ramon and Shahrdad: We had our first meeting last Thursday. There is definitely some interest in Erlang in Montreal, though lacking major software houses using it probably makes it more of an off-work-hours area of interest! To keep taps on what is happening at Erlang Montreal, see: 1) Google Group: http://groups.google.com/group/erlang-montreal 2) EUG-Canada LinkedIn sub-group: http://www.linkedin.com/groups?mostPopular=&gid=3838220 -signed(ahmed). On 5/15/11 12:03 AM, cognition.mind wrote: > I live in Gatineau, but sounds like an idea, > I just started learning erlang and have come to really love it, > > Keep me posted if anything gets moving. > > Cheers > Ramon > > ----- > Empires fall. Religions dissolve like mist. But quotes about monkeys with keyboards live for eternity. > - The Covert Comic > -- > View this message in context: http://erlang.2086793.n4.nabble.com/Erlangers-in-Montreal-tp3388272p3523815.html > Sent from the Erlang Questions mailing list archive at Nabble.com. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From bengt.kleberg@REDACTED Wed May 18 08:14:37 2011 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Wed, 18 May 2011 08:14:37 +0200 Subject: [erlang-questions] 'reply-to' header in this mailing list In-Reply-To: References: <20110517142848.GA9263@erix.ericsson.se> <230D6DBF-EE90-475F-A973-DF0E7B71EF19@cs.otago.ac.nz> Message-ID: <1305699277.7633.13.camel@seasc1137> Greetings, Another possible take on what the proper behaviour should be, is perhaps found when thinking about the question: Which rule minimises the amount of damage if I misunderstand it? Say that I want to reply to one person only and use Reply-to when the rule is to send to the whole list. It is a possible misunderstanding and would be damaging if the email goes out to everybody. On the other hand, I want to reply to all and use Reply-to when the rule is to send to the author only. It is a possible misunderstanding and only one person gets the email. I will notice this when it never reaches the list. I can then resend it to everybody. More work, but no damage. bengt On Wed, 2011-05-18 at 07:35 +0200, Michael Turner wrote: > Does anyone have any statistics on this question? That is, what > percentage of mailing lists "do it wrong"? It's counterintuitive to me > that a "reply" on this mailing list is only to the individual. > "Reply" is "Reply to the list" on every other mailing list I'm > currently on, and on almost every mailing list I can remember being > on. But perhaps my lifetime mailing list membership doesn't approach > statistical significance. > > > Although it may get me accused of "blindly following the herd," let me > assert it anyway: arguments from "intuition" in commonly used software > interfaces only work when you have statistically significant user > support for them, not some purely formal, rule-based argument for your > *personal* intuition. What's "intuitive" to one person may be > counterintuitive to many. As pointed out long ago, "intuitive equals > familiar": > > > http://www.asktog.com/papers/raskinintuit.html > > > And, as pointed out even longer ago, "a foolish consistency is the > hobgoblin of small minds." (Emerson.) > > > Perhaps to some people, a mailing list is like a noticeboard in a > mostly-empty hallway. My mental model of a mailing list corresponds > more closely to a conversation in a classroom. When you reply to an > open question or comment in such a context, you cannot help but be > heard by more than one person; most likely you'll be heard by everyone > in the room. You actually have to make a special effort (i.e., lean > over and whisper in an ear, or pass a note) to be sure that your reply > is private. I think this corresponds pretty closely to the intuition > of the average mailing list user. But erlangeurs may be different, I > don't know. > > > -michael turner > > > > > On Wed, May 18, 2011 at 8:45 AM, Richard O'Keefe > wrote: > > On 18/05/2011, at 3:07 AM, Alexander Krasnukhin wrote: > > > Yes, yes. I've got this. People from telecom will always > rely on standards instead of people expectations. Good. Right. > Understandable. > > > That sounds a bit sarcastic. > The thing is that the Erlang mailing list behaves *EXACTLY* > the way I expect > a mailing list to work. > I expect "Reply All" to reply to everyone on the list. > I expect "Reply" to go just to the author. > I expect it to work the way mailing lists always used to work. > > The standard in this case is not arbitrary, but part of a > coherent > design to ensure a straightforward user experience. > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > From ulf.wiger@REDACTED Wed May 18 09:02:36 2011 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Wed, 18 May 2011 09:02:36 +0200 Subject: [erlang-questions] What are the "Most valuable libraries?"...and a few other questions In-Reply-To: <4DD311FF.2090402@gmail.com> References: <20110517142848.GA9263@erix.ericsson.se> <230D6DBF-EE90-475F-A973-DF0E7B71EF19@cs.otago.ac.nz> <4DD311FF.2090402@gmail.com> Message-ID: On 18 May 2011, at 02:25, Todd wrote: > 3. How does one easily multithread an app? For instance, there's pmap in clojure and something similar in akka that lets you map a function across a list, and it allocates threads accordingly... > > literally something like: "pmap(myfun, mylist);" The thing that makes Erlang a bit different here is that it is concurrency-oriented from the start. That is, you approach the concurrency model as a fundamental part of your functional design. From that perspective, the "multithreading" of an app might be exploiting in-process concurrency, or otherwise tweaking the "ideal" concurrency model for speed. For this, there is no easy answer, but surprisingly often, an application using textbook Erlang techniques for its concurrency model will get very good utilisation of multicore hardware. I gave a presentation in 2009 about how writing a generic "one-size-fits-all" pmap in Erlang is less than straightforward. http://www.infoq.com/presentations/wiger-multicore-erlang The good news is that it is not that hard to write a custom pmap that suits your particular needs, and this echoes the sentiments expressed in a recent thread about behaviours here on the list: learn the basic patterns, and their intrinsic semantics. Once you understand the mechanics, you can use behaviours where they are a good fit. BR, Ulf W Ulf Wiger, CTO, Erlang Solutions, Ltd. http://erlang-solutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From olopierpa@REDACTED Wed May 18 09:38:21 2011 From: olopierpa@REDACTED (Pierpaolo Bernardi) Date: Wed, 18 May 2011 09:38:21 +0200 Subject: [erlang-questions] 'reply-to' header in this mailing list In-Reply-To: References: <20110517142848.GA9263@erix.ericsson.se> <230D6DBF-EE90-475F-A973-DF0E7B71EF19@cs.otago.ac.nz> Message-ID: On Wed, May 18, 2011 at 07:35, Michael Turner wrote: > Does anyone have any statistics on this question? That is, what percentage > of mailing lists "do it wrong"? It's counterintuitive to me that ?a "reply" > on this mailing list is only to the individual. "Reply" is "Reply to the > list" on every other mailing list I'm currently on, and on almost every > mailing list I can remember being on. But perhaps my lifetime mailing list > membership doesn't approach statistical significance. > Although it may get me accused of "blindly following the herd," let me > assert it anyway: arguments from "intuition" in commonly used software > interfaces only work when you have statistically significant user support > for them, not some purely formal, rule-based argument for your *personal* > intuition. What's "intuitive" to one person may be counterintuitive to many. According to your intuition, what should be the difference between an action called "Reply" and another called "Reply to all"? From freza@REDACTED Wed May 18 10:18:34 2011 From: freza@REDACTED (Jachym Holecek) Date: Wed, 18 May 2011 09:18:34 +0100 Subject: [erlang-questions] About error enfile? In-Reply-To: References: Message-ID: <20110518081834.GA1762@hanele.lan> # yaohui 2011-05-18: > [... diagnostics ...] > > dmesg out of socket memory apper When a piece of software dumps odd messages on you, it usually helps to cut'n'paste them to Google or grep through that software's sources. The former points us to: http://redmine.lighttpd.net/issues/545 http://fasterdata.es.net/fasterdata/host-tuning/linux/ http://www.readmespot.com/question/f/106537/tuning-linux-ip-routing-parameters----secret_interval-and-tcp_mem BR, -- Jachym From freza@REDACTED Wed May 18 10:34:22 2011 From: freza@REDACTED (Jachym Holecek) Date: Wed, 18 May 2011 09:34:22 +0100 Subject: [erlang-questions] supervisor children's pid In-Reply-To: <20110518044824.GC7320@aluminum.local> References: <20110518044824.GC7320@aluminum.local> Message-ID: <20110518083422.GB1762@hanele.lan> # Vance Shipley 2011-05-18: > On Wed, May 18, 2011 at 12:37:02AM +0200, Roberto Ostinelli wrote: > } currently, i'm calling supervisor:which_children/1 on the init function of > } the gen_servers, and match the Ids to get the Child [Pid]. > > You can't call the supervisor from the init function of one of it's > own children. You have to return from init/1 before that is possible. > > What you can do is to return {ok, State, Timeout} from init/1 with > a Timeout value of 0 and go on with the initialization after the > supervisor has completed starting the children. The attached example > uses a psuedo state to carry on with the initialization: > > 1> supervisor:start_link(which_sup, []). > Server=1, Siblings=[<0.36.0>,<0.35.0>] > Server=2, Siblings=[<0.36.0>,<0.34.0>] > Server=3, Siblings=[<0.35.0>,<0.34.0>] > {ok,<0.33.0>} Nice trick, but there is no guarantee process' siblings will already be started after some arbitrary timeout -- try this on a heavily loaded system... it's just not safe. > } is this the best strategy to achieve this? > > Yes, use supervisor:which_children/1 to learn the siblings. No, if he's using anything other than one_for_all strategy the Pids he learns this way may become stale in the future. Usual ways to handle this: * Register the processes, if the names need to be dynamic supervisor can compute them at init/1 and pass to children in arguments. * Run a name resolution server somewhere and have all the children subscribe to it. The server will monitor them and may provide notification facility to announce Pid changes/availability to anyone interested -- this lets you do safe startup of dependent processes. * In some cases, you'd start_link those child processes from one master server directly (not from supervisor), and use their Pids directly. Only makes sense if they're very closely bound. * Probably something else I can't remember right now. :-) HTH, -- Jachym From michael.eugene.turner@REDACTED Wed May 18 10:36:43 2011 From: michael.eugene.turner@REDACTED (Michael Turner) Date: Wed, 18 May 2011 17:36:43 +0900 Subject: [erlang-questions] 'reply-to' header in this mailing list In-Reply-To: References: <20110517142848.GA9263@erix.ericsson.se> <230D6DBF-EE90-475F-A973-DF0E7B71EF19@cs.otago.ac.nz> Message-ID: Pierpalo asks: "According to your intuition, what should be the difference between an action called "Reply" and another called "Reply to all"?" My intuitions about what ANY response should be to ANY request for action depend on my personal experience and on the circumstances of the request. And I'm hardly alone in that. In user interface design, this is called "The Principle of Least Astonishment." http://en.wikipedia.org/wiki/Principle_of_least_astonishment On a mailing list, I'm slightly astonished ("dismayed" would be a better word) when I reply to the list (or so I think) and discover later (IF I ever do) that the reply went to an individual instead. Here, I would expect "Reply" and "Reply to all" to do the same thing. That's redundant, you say? Well, so what? Life is redundant. Then you die. I understand the argument from risk: Yes, every so often, somebody thinks they are replying to an individual when in fact they are replying to the list. I've done this mysefl, and suffered embarrassment. But risk correlates with reward, as with anything in life, and a mailing list is *always* a balance between individual risks of embarrassment ("Will I seem stupid to some people? Will the answer to my question come to me a second after I hit Send? Was there an embarrassing typo in what I wrote?") and collective reward: everybody gets to see the answers; the only people who lose are those who find the answer--or the inbox clutter--annoying. (Presumably, the signal averages out to be positive for most; and for those for whom it doesn't, unsubscribing is always an option.) So, in this case, doing the more expected, less astonishing thing is quite aligned with the spirit of mailing lists, even if it's in violation of the letter of IETF law. Sometimes, the most rational thing to do is not the purely logical thing to do. In those cases, I side with rationality. But look: there's cultural variation. Maybe most people in the Erlang world have different expectations or thresholds of "astonishment". So the most rational thing would probably be to put it to a vote, on the list. After all, the issue's just going to come up again, chewing up yet more of that "bandwidth" that Raimo's so worried about conserving. So why not just find out what most people want and do that? -michael turner On Wed, May 18, 2011 at 4:38 PM, Pierpaolo Bernardi wrote: > On Wed, May 18, 2011 at 07:35, Michael Turner > wrote: > > Does anyone have any statistics on this question? That is, what > percentage > > of mailing lists "do it wrong"? It's counterintuitive to me that a > "reply" > > on this mailing list is only to the individual. "Reply" is "Reply to the > > list" on every other mailing list I'm currently on, and on almost every > > mailing list I can remember being on. But perhaps my lifetime mailing > list > > membership doesn't approach statistical significance. > > Although it may get me accused of "blindly following the herd," let me > > assert it anyway: arguments from "intuition" in commonly used software > > interfaces only work when you have statistically significant user support > > for them, not some purely formal, rule-based argument for your *personal* > > intuition. What's "intuitive" to one person may be counterintuitive to > many. > > According to your intuition, what should be the difference between > an action called "Reply" and another called "Reply to all"? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lenartlad@REDACTED Wed May 18 10:51:11 2011 From: lenartlad@REDACTED (Ladislav Lenart) Date: Wed, 18 May 2011 10:51:11 +0200 Subject: [erlang-questions] 'reply-to' header in this mailing list In-Reply-To: References: <20110517142848.GA9263@erix.ericsson.se> <230D6DBF-EE90-475F-A973-DF0E7B71EF19@cs.otago.ac.nz> Message-ID: <4DD3887F.8070607@volny.cz> Hello. On 18.5.2011 09:38, Pierpaolo Bernardi wrote: > On Wed, May 18, 2011 at 07:35, Michael Turner > wrote: >> Does anyone have any statistics on this question? That is, what percentage >> of mailing lists "do it wrong"? It's counterintuitive to me that a "reply" >> on this mailing list is only to the individual. "Reply" is "Reply to the >> list" on every other mailing list I'm currently on, and on almost every >> mailing list I can remember being on. But perhaps my lifetime mailing list >> membership doesn't approach statistical significance. >> Although it may get me accused of "blindly following the herd," let me >> assert it anyway: arguments from "intuition" in commonly used software >> interfaces only work when you have statistically significant user support >> for them, not some purely formal, rule-based argument for your *personal* >> intuition. What's "intuitive" to one person may be counterintuitive to many. > > According to your intuition, what should be the difference between > an action called "Reply" and another called "Reply to all"? But this does not take into account that most users of this mailing list are already familiar with the way other mailing lists work. They already know (perhaps by trial and error from a long ago) that "Reply" replies to all the list members. And in this situation this mailing list is the one that breaks their "intuition" (habit, familiarity). Your question works only for a first time mailing list user with no previous exposure to any mailing list. In such a situation the labels "Reply" and "Reply to all" will be all the information she has to decide. Ladislav Lenart PS: I am not biased to any side on this one. From olopierpa@REDACTED Wed May 18 10:54:53 2011 From: olopierpa@REDACTED (Pierpaolo Bernardi) Date: Wed, 18 May 2011 10:54:53 +0200 Subject: [erlang-questions] 'reply-to' header in this mailing list In-Reply-To: References: <20110517142848.GA9263@erix.ericsson.se> <230D6DBF-EE90-475F-A973-DF0E7B71EF19@cs.otago.ac.nz> Message-ID: On Wed, May 18, 2011 at 10:28, Alex Shneyderman wrote: >> According to your intuition, what should be the difference between >> an action called "Reply" and another called "Reply to all"? > > In the case of this list (or any mailing list) I would expect reply to > go to the list > because I am aware of the fact that the discussion is to be conducted on > that list. If I want to make sure that the email goes to the original author I > will take extra care/effort to send the reply to that one person. > > And it is not just his intuition - my intuition tells me the same > thing as his :-) OK. That would be my intuition, too, if there was only one action available for replying to messages. But in every modern mail client there are two possibilities, usually labeled something like "reply" and "reply to all", so my question still stands unanswered. The people who complain about the correct behaviour could easily obtain their desired behaviour if they just *don't* use the "reply" command (Never. Not only for messages coming from properly configured mailing lists), and *always* use "reply to all" (Always. Not only for for messages coming for properly configured mailing lists). I would like to understand *why* you don't judge this very simple solution to your problem as adeguate. Really. Mine is not a rethorical question. P. From ivan@REDACTED Wed May 18 10:55:19 2011 From: ivan@REDACTED (Ivan Uemlianin) Date: Wed, 18 May 2011 09:55:19 +0100 Subject: [erlang-questions] 'reply-to' header in this mailing list In-Reply-To: <4DD3887F.8070607@volny.cz> References: <20110517142848.GA9263@erix.ericsson.se> <230D6DBF-EE90-475F-A973-DF0E7B71EF19@cs.otago.ac.nz> <4DD3887F.8070607@volny.cz> Message-ID: <4DD38977.2070507@llaisdy.com> Thunderbird has a "reply list" option in the GUI, so this issue must have been sufficiently annoying to the hackers at the Mozilla Foundation. Ivan -- ============================================================ Ivan A. Uemlianin Speech Technology Research and Development ivan@REDACTED www.llaisdy.com llaisdy.wordpress.com www.linkedin.com/in/ivanuemlianin "Froh, froh! Wie seine Sonnen, seine Sonnen fliegen" (Schiller, Beethoven) ============================================================ From langxianzhe@REDACTED Wed May 18 10:57:33 2011 From: langxianzhe@REDACTED (=?GB2312?B?wMnPzM7k?=) Date: Wed, 18 May 2011 16:57:33 +0800 Subject: [erlang-questions] about erlang eprof tool. Why is the handle_info and handle_cast without in the result Message-ID: hi everybody: I write a test 'chat' code with eprof. I have found the handle_info and handle_cast functions without in the anaylise result. Why ? thanks Regards jason 1 -module(chat). 2 -compile(export_all). 3 %-behaviour(gen_server). 4 start(N) -> 5 start_link(), 6 eprof:start(), 7 eprof:start_profiling([chat]), 8 test(N), 9 testcast(), 10 test(), 11 eprof:stop_profiling(), 12 eprof:log(chat), 13 eprof:analyse(), 14 eprof:total_analyse(). 15 16 test(N)-> 17 gen_server:call(?MODULE, {test,N}). 18 test()-> 19 chat ! {test,1}. 20 testcast() -> 21 gen_server:cast(?MODULE,castttt). 22 23 start_link() -> 24 gen_server:start_link({local,?MODULE},?MODULE,[],[]). 25 26 init([]) -> 27 {ok, {}}. 28 29 handle_cast(Msg,State) -> 30 tttt(), 31 io:format("cast=~p~n",[Msg]), 32 {noreply,State}. 33 34 handle_call({test,Number},From, State) when is_number(Number) -> 35 Reply = Number+1, 36 {reply, Reply,State}; 37 38 handle_call(_,From, State) -> 39 Reply = numerror, 40 {reply, Reply,State}. 41 handle_info(Ino,State) -> 42 tttt(), 43 io:format("info=~p~n",[Ino]), 44 {noreply,State}. 45 tttt() -> 46 ok. %%%%%%%%%%%%%%%%% Test result 5> chat:start(1). eprof: Starting profiling ..... eprof: Stop profiling cast=castttt info={test,1} FUNCTION CALLS TIME ****** Process <0.35.0> -- 100 % of profiled time *** gen_server:loop/6 1 30 % gen_server:handle_msg/5 1 28 % chat:handle_call/3 1 21 % gen_server:reply/2 1 14 % gen_server:decode_msg/8 1 8 % Total time: 0.00 Measurement overhead: 0.00 FUNCTION CALLS TIME gen_server:loop/6 1 30 % gen_server:handle_msg/5 1 28 % chat:handle_call/3 1 21 % gen_server:reply/2 1 14 % gen_server:decode_msg/8 1 8 % Total time: 0.00 Measurement overhead: 0.00 ok 6> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: chat.erl Type: text/x-erlang Size: 924 bytes Desc: not available URL: From michael.eugene.turner@REDACTED Wed May 18 11:16:27 2011 From: michael.eugene.turner@REDACTED (Michael Turner) Date: Wed, 18 May 2011 18:16:27 +0900 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions Message-ID: I can say fun (1)->2; (2)->1 end but, oddly, I can't define a named function in the analogous way, e.g.: factorial (1) -> 1; (N) -> N*factorial(N-1). gives me a syntax error. I find the latter more readable than factorial(1) -> 1; factorial(2) -> N*fact(N-1). It's also less to type and to read, which is consistent with the DRY principle ("Don't Repeat Yourself"). And it lends itself to reading a function definition as a set of cases. I think for Erlang newbies, it should therefore would be preferred: it helps underscore the pattern-matching style of Erlang function invocation. It also looks a *little* bit more like the mathematical convention for defining these sorts of functions, where you have "f(x) = ", centered vertically to the left of a big left "{" that (left-)encloses the list of expression/parameter-condition pairs in a two-column format, e.g., http://cnx.org/content/m29517/latest/Picture%2047.png So there's a (weak) argument from the Principle of Least Surprise here as well. It seems to me that, if anything, this requires only a *simplification* of the Erlang parser. That leaves only one obvious objection: would any existing code break if Erlang syntax were altered to allow this? -michael turner -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto@REDACTED Wed May 18 11:26:54 2011 From: roberto@REDACTED (Roberto Ostinelli) Date: Wed, 18 May 2011 11:26:54 +0200 Subject: [erlang-questions] supervisor children's pid In-Reply-To: <20110518083422.GB1762@hanele.lan> References: <20110518044824.GC7320@aluminum.local> <20110518083422.GB1762@hanele.lan> Message-ID: > > } is this the best strategy to achieve this? > > > > Yes, use supervisor:which_children/1 to learn the siblings. > > No, if he's using anything other than one_for_all strategy the Pids > he learns this way may become stale in the future. > fortunately, it is a one_for_all strategy, but good point. Usual ways to handle this: > > * Register the processes, if the names need to be dynamic supervisor > can compute them at init/1 and pass to children in arguments. > no can do, these have to be anonymous. > * Run a name resolution server somewhere and have all the children > subscribe to it. The server will monitor them and may provide > notification facility to announce Pid changes/availability to > anyone interested -- this lets you do safe startup of dependent > processes. > probably the best would be then to have a gen_event module for this. this is a good idea. > * In some cases, you'd start_link those child processes from one > master server directly (not from supervisor), and use their Pids > directly. Only makes sense if they're very closely bound. > i'm adding supervisors because i need it to be as OTP compliant as possible, so I'm actually moving away from this solution. thank you very much vance and jachym for these insights. r. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto@REDACTED Wed May 18 11:38:50 2011 From: roberto@REDACTED (Roberto Ostinelli) Date: Wed, 18 May 2011 11:38:50 +0200 Subject: [erlang-questions] supervisor started from gen_server Message-ID: Hello all, just a quick question: can you think of any case in which starting a supervisor from a gen_server would actually be a perfectly fit idea? I tend to think of this with some relevant dose of fear, but I'd like to hear any opinion on this. Thank you, r. -------------- next part -------------- An HTML attachment was scrubbed... URL: From demeshchuk@REDACTED Wed May 18 11:44:50 2011 From: demeshchuk@REDACTED (Dmitry Demeshchuk) Date: Wed, 18 May 2011 13:44:50 +0400 Subject: [erlang-questions] supervisor started from gen_server In-Reply-To: References: Message-ID: Sounds ridiculous. Supervisor should be started either by an application as the root one, or by a higher-level supervisor. Most likely, if you try starting it within gen_server, gen_fsm or whatever, you'll end up with writing your own supervisor based on gen_server, gen_fsm or whatever. Or you will have a failure point, which is as bad. On Wed, May 18, 2011 at 1:38 PM, Roberto Ostinelli wrote: > Hello all, > > just a quick question: can you think of any case in which starting a > supervisor from a gen_server would actually be a perfectly fit idea? I tend > to think of this with some relevant dose of fear, but I'd like to hear any > opinion on this. > > Thank you, > > r. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- Best regards, Dmitry Demeshchuk From robert.virding@REDACTED Wed May 18 11:44:59 2011 From: robert.virding@REDACTED (Robert Virding) Date: Wed, 18 May 2011 09:44:59 +0000 (GMT) Subject: [erlang-questions] supervisor children's pid In-Reply-To: <1198361206.195961305704637029.JavaMail.root@zimbra> Message-ID: <2079625790.196771305711899307.JavaMail.root@zimbra> After the supervisor has started a child server won't it then be running completely unsynchronised with the supervisor? In that case how will a server know that all the other servers have been started? Robert ----- "Vance Shipley" wrote: > On Wed, May 18, 2011 at 12:37:02AM +0200, Roberto Ostinelli wrote: > } currently, i'm calling supervisor:which_children/1 on the init > function of > } the gen_servers, and match the Ids to get the Child [Pid]. > > You can't call the supervisor from the init function of one of it's > own children. You have to return from init/1 before that is > possible. > > What you can do is to return {ok, State, Timeout} from init/1 with > a Timeout value of 0 and go on with the initialization after the > supervisor has completed starting the children. The attached example > uses a psuedo state to carry on with the initialization: > > 1> supervisor:start_link(which_sup, []). > Server=1, Siblings=[<0.36.0>,<0.35.0>] > Server=2, Siblings=[<0.36.0>,<0.34.0>] > Server=3, Siblings=[<0.35.0>,<0.34.0>] > {ok,<0.33.0>} > > } is this the best strategy to achieve this? > > Yes, use supervisor:which_children/1 to learn the siblings. > > > -- > -Vance > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From michael.eugene.turner@REDACTED Wed May 18 12:00:40 2011 From: michael.eugene.turner@REDACTED (Michael Turner) Date: Wed, 18 May 2011 19:00:40 +0900 Subject: [erlang-questions] 'reply-to' header in this mailing list In-Reply-To: References: <20110517142848.GA9263@erix.ericsson.se> <230D6DBF-EE90-475F-A973-DF0E7B71EF19@cs.otago.ac.nz> Message-ID: "I would like to understand *why* you don't judge this very simple solution to your problem as adeguate." It's not just about me. It's about people who have never encountered this controversy before, because they're on normal mailing lists, and who write their first-ever message (and many more afterward) to *this* list. People who haven't even subscribed yet. So, what do you propose? Something like this, perhaps: In the sign-on message for new subscribers to the Erlang mailing list, we include a message saying, "Get in the habit of always using 'Reply all' instead of 'Reply', for *all* of your e-mail correspondence, and after a while, you won't find it annoying in the least that this mailing list has 'Reply-to' set only to the address of the message sender, unlike other mailing lists you're on." Or, if not that, then exactly *how* do you propose to change the world's habits? (Venture Capitalists have a term for this, when they encounter a business plan that's predicated on people giving up habits: "Boiling the ocean.") When it's "purely logical versus human nature", human nature always wins. -michael turner On Wed, May 18, 2011 at 5:54 PM, Pierpaolo Bernardi wrote: > On Wed, May 18, 2011 at 10:28, Alex Shneyderman > wrote: > >> According to your intuition, what should be the difference between > >> an action called "Reply" and another called "Reply to all"? > > > > In the case of this list (or any mailing list) I would expect reply to > > go to the list > > because I am aware of the fact that the discussion is to be conducted on > > that list. If I want to make sure that the email goes to the original > author I > > will take extra care/effort to send the reply to that one person. > > > > And it is not just his intuition - my intuition tells me the same > > thing as his :-) > > OK. That would be my intuition, too, if there was only one action > available for replying to messages. But in every modern mail client > there are two possibilities, usually labeled something like "reply" > and "reply to all", so my question still stands unanswered. > > The people who complain about the correct behaviour could easily > obtain their desired behaviour if they just *don't* use the "reply" > command (Never. Not only for messages coming from properly > configured mailing lists), and *always* use "reply to all" (Always. > Not only for for messages coming for properly configured mailing lists). > > I would like to understand *why* you don't judge this very simple > solution to your problem as adeguate. Really. Mine is not a > rethorical question. > > P. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From spawn.think@REDACTED Wed May 18 12:05:08 2011 From: spawn.think@REDACTED (Ahmed Omar) Date: Wed, 18 May 2011 12:05:08 +0200 Subject: [erlang-questions] about erlang eprof tool. Why is the handle_info and handle_cast without in the result In-Reply-To: References: Message-ID: Sending a message (handled by handle_info) or doing a cast (handled by handle_cast) are both async. You are stopping the profiler too early. Changing the order to do the async operations first, then the sync one should assure that all the requests have been handled before you stop eprof On Wed, May 18, 2011 at 10:57 AM, ??? wrote: > hi everybody: > I write a test 'chat' code with eprof. > I have found the handle_info and handle_cast functions without in the > anaylise result. > Why ? > > thanks > Regards > jason > > 1 -module(chat). > > > 2 -compile(export_all). > 3 %-behaviour(gen_server). > 4 start(N) -> > 5 start_link(), > 6 eprof:start(), > 7 eprof:start_profiling([chat]), > 8 test(N), > 9 testcast(), > 10 test(), > 11 eprof:stop_profiling(), > 12 eprof:log(chat), > 13 eprof:analyse(), > 14 eprof:total_analyse(). > 15 > 16 test(N)-> > 17 gen_server:call(?MODULE, {test,N}). > 18 test()-> > 19 chat ! {test,1}. > 20 testcast() -> > 21 gen_server:cast(?MODULE,castttt). > 22 > 23 start_link() -> > 24 gen_server:start_link({local,?MODULE},?MODULE,[],[]). > 25 > 26 init([]) -> > 27 {ok, {}}. > 28 > 29 handle_cast(Msg,State) -> > 30 tttt(), > 31 io:format("cast=~p~n",[Msg]), > 32 {noreply,State}. > 33 > 34 handle_call({test,Number},From, State) when is_number(Number) -> > 35 Reply = Number+1, > 36 {reply, Reply,State}; > 37 > 38 handle_call(_,From, State) -> > 39 Reply = numerror, > 40 {reply, Reply,State}. > 41 handle_info(Ino,State) -> > 42 tttt(), > 43 io:format("info=~p~n",[Ino]), > 44 {noreply,State}. > 45 tttt() -> > 46 ok. > %%%%%%%%%%%%%%%%% > Test result > 5> chat:start(1). > eprof: Starting profiling ..... > eprof: Stop profiling > cast=castttt > info={test,1} > FUNCTION CALLS TIME > > ****** Process <0.35.0> -- 100 % of profiled time *** > gen_server:loop/6 1 30 % > gen_server:handle_msg/5 1 28 % > chat:handle_call/3 1 21 % > gen_server:reply/2 1 14 % > gen_server:decode_msg/8 1 8 % > > Total time: 0.00 > Measurement overhead: 0.00 > FUNCTION CALLS TIME > gen_server:loop/6 1 30 % > gen_server:handle_msg/5 1 28 % > chat:handle_call/3 1 21 % > gen_server:reply/2 1 14 % > gen_server:decode_msg/8 1 8 % > > Total time: 0.00 > Measurement overhead: 0.00 > ok > 6> > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.virding@REDACTED Wed May 18 12:15:43 2011 From: robert.virding@REDACTED (Robert Virding) Date: Wed, 18 May 2011 10:15:43 +0000 (GMT) Subject: [erlang-questions] 'reply-to' header in this mailing list In-Reply-To: Message-ID: <90290842.196921305713743674.JavaMail.root@zimbra> I have so far studiously avoided getting in any of these discussions. I personally think that the current way is what best corresponds to my view of a mailing-list, it is a list mail addresses. When I post to the list I am really just sending to all the people on the list, it is a practical and simple way of keeping track of to whom I am sending. So a reply is a reply to the sender. This maybe a slightly na?ve way of viewing a list but to me this is what a mailing-list is. If it were a forum, which I think it should be, then it would be a different matter. Robert ----- "Michael Turner" wrote: > " I would like to understand *why* you don't judge this very simple solution to your problem as adeguate." > It's not just about me. It's about people who have never encountered this controversy before, because they're on normal mailing lists, and who write their first-ever message (and many more afterward) to *this* list. People who haven't even subscribed yet. > So, what do you propose? Something like this, perhaps: In the sign-on message for new subscribers to the Erlang mailing list, we include a message saying, "Get in the habit of always using 'Reply all' instead of 'Reply', for *all* of your e-mail correspondence, and after a while, you won't find it annoying in the least that this mailing list has 'Reply-to' set only to the address of the message sender, unlike other mailing lists you're on." > Or, if not that, then exactly *how* do you propose to change the world's habits? (Venture Capitalists have a term for this, when they encounter a business plan that's predicated on people giving up habits: "Boiling the ocean.") > When it's "purely logical versus human nature", human nature always wins. > -michael turner > > > On Wed, May 18, 2011 at 5:54 PM, Pierpaolo Bernardi < olopierpa@REDACTED > wrote: > > On Wed, May 18, 2011 at 10:28, Alex Shneyderman < a.shneyderman@REDACTED > wrote: > >> According to your intuition, what should be the difference between > >> an action called "Reply" and another called "Reply to all"? > > > > In the case of this list (or any mailing list) I would expect reply to > > go to the list > > because I am aware of the fact that the discussion is to be conducted on > > that list. If I want to make sure that the email goes to the original author I > > will take extra care/effort to send the reply to that one person. > > > > And it is not just his intuition - my intuition tells me the same > > thing as his :-) > > OK. That would be my intuition, too, if there was only one action > available for replying to messages. But in every modern mail client > there are two possibilities, usually labeled something like "reply" > and "reply to all", so my question still stands unanswered. > > The people who complain about the correct behaviour could easily > obtain their desired behaviour if they just *don't* use the "reply" > command (Never. Not only for messages coming from properly > configured mailing lists), and *always* use "reply to all" (Always. > Not only for for messages coming for properly configured mailing lists). > > I would like to understand *why* you don't judge this very simple > solution to your problem as adeguate. Really. Mine is not a > rethorical question. > > P. > > > _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From langxianzhe@REDACTED Wed May 18 12:20:22 2011 From: langxianzhe@REDACTED (jasonlxw) Date: Wed, 18 May 2011 03:20:22 -0700 (PDT) Subject: [erlang-questions] about erlang eprof tool. Why is the handle_info and handle_cast without in the result In-Reply-To: References: Message-ID: I try to do after adding seelp. It is ok . You are right. Thank you, 2011/5/18 Ahmed Omar [via Erlang] < ml-node+3532180-407008175-67370@REDACTED> > Sending a message (handled by handle_info) or doing a cast (handled by > handle_cast) are both async. > You are stopping the profiler too early. > Changing the order to do the async operations first, then the sync one > should assure that all the requests have been handled before you stop eprof > > On Wed, May 18, 2011 at 10:57 AM, ??? <[hidden email] > > wrote: > >> hi everybody: >> I write a test 'chat' code with eprof. >> I have found the handle_info and handle_cast functions without in the >> anaylise result. >> Why ? >> >> thanks >> Regards >> jason >> >> 1 -module(chat). >> >> >> 2 -compile(export_all). >> 3 %-behaviour(gen_server). >> 4 start(N) -> >> 5 start_link(), >> 6 eprof:start(), >> 7 eprof:start_profiling([chat]), >> 8 test(N), >> 9 testcast(), >> 10 test(), >> 11 eprof:stop_profiling(), >> 12 eprof:log(chat), >> 13 eprof:analyse(), >> 14 eprof:total_analyse(). >> 15 >> 16 test(N)-> >> 17 gen_server:call(?MODULE, {test,N}). >> 18 test()-> >> 19 chat ! {test,1}. >> 20 testcast() -> >> 21 gen_server:cast(?MODULE,castttt). >> 22 >> 23 start_link() -> >> 24 gen_server:start_link({local,?MODULE},?MODULE,[],[]). >> 25 >> 26 init([]) -> >> 27 {ok, {}}. >> 28 >> 29 handle_cast(Msg,State) -> >> 30 tttt(), >> 31 io:format("cast=~p~n",[Msg]), >> 32 {noreply,State}. >> 33 >> 34 handle_call({test,Number},From, State) when is_number(Number) -> >> 35 Reply = Number+1, >> 36 {reply, Reply,State}; >> 37 >> 38 handle_call(_,From, State) -> >> 39 Reply = numerror, >> 40 {reply, Reply,State}. >> 41 handle_info(Ino,State) -> >> 42 tttt(), >> 43 io:format("info=~p~n",[Ino]), >> 44 {noreply,State}. >> 45 tttt() -> >> 46 ok. >> %%%%%%%%%%%%%%%%% >> Test result >> 5> chat:start(1). >> eprof: Starting profiling ..... >> eprof: Stop profiling >> cast=castttt >> info={test,1} >> FUNCTION CALLS TIME >> >> ****** Process <0.35.0> -- 100 % of profiled time *** >> gen_server:loop/6 1 30 % >> gen_server:handle_msg/5 1 28 % >> chat:handle_call/3 1 21 % >> gen_server:reply/2 1 14 % >> gen_server:decode_msg/8 1 8 % >> >> Total time: 0.00 >> Measurement overhead: 0.00 >> FUNCTION CALLS TIME >> gen_server:loop/6 1 30 % >> gen_server:handle_msg/5 1 28 % >> chat:handle_call/3 1 21 % >> gen_server:reply/2 1 14 % >> gen_server:decode_msg/8 1 8 % >> >> Total time: 0.00 >> Measurement overhead: 0.00 >> ok >> 6> >> >> >> _______________________________________________ >> erlang-questions mailing list >> [hidden email] >> >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > > > -- > Best Regards, > - Ahmed Omar > http://nl.linkedin.com/in/adiaa > Follow me on twitter > @spawn_think > > > _______________________________________________ > erlang-questions mailing list > [hidden email] > http://erlang.org/mailman/listinfo/erlang-questions > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://erlang.2086793.n4.nabble.com/about-erlang-eprof-tool-Why-is-the-handle-info-and-handle-cast-without-in-the-result-tp3532017p3532180.html > To start a new topic under Erlang Questions, email > ml-node+2086794-1604045721-67370@REDACTED > To unsubscribe from Erlang Questions, click here. > > ----- Never give up -- View this message in context: http://erlang.2086793.n4.nabble.com/about-erlang-eprof-tool-Why-is-the-handle-info-and-handle-cast-without-in-the-result-tp3532017p3532216.html Sent from the Erlang Questions mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimo+erlang-questions@REDACTED Wed May 18 12:25:44 2011 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Wed, 18 May 2011 12:25:44 +0200 Subject: [erlang-questions] 'reply-to' header in this mailing list In-Reply-To: References: <20110517142848.GA9263@erix.ericsson.se> <230D6DBF-EE90-475F-A973-DF0E7B71EF19@cs.otago.ac.nz> Message-ID: <20110518102544.GA4121@erix.ericsson.se> On Wed, May 18, 2011 at 05:36:43PM +0900, Michael Turner wrote: : > thing would probably be to put it to a vote, on the list. After all, the > issue's just going to come up again, chewing up yet more of that "bandwidth" > that Raimo's so worried about conserving. So why not just find out what most That was an expression that means mine and others mental bandwidth. > people want and do that? > > -michael turner -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From olopierpa@REDACTED Wed May 18 12:32:10 2011 From: olopierpa@REDACTED (Pierpaolo Bernardi) Date: Wed, 18 May 2011 12:32:10 +0200 Subject: [erlang-questions] 'reply-to' header in this mailing list In-Reply-To: References: <20110517142848.GA9263@erix.ericsson.se> <230D6DBF-EE90-475F-A973-DF0E7B71EF19@cs.otago.ac.nz> Message-ID: On Wed, May 18, 2011 at 12:00, Michael Turner wrote: > So, what do you propose? I propose doing nothing. 8^) Cheers P. From vances@REDACTED Wed May 18 13:53:59 2011 From: vances@REDACTED (Vance Shipley) Date: Wed, 18 May 2011 17:23:59 +0530 Subject: [erlang-questions] supervisor children's pid In-Reply-To: <2079625790.196771305711899307.JavaMail.root@zimbra> References: <1198361206.195961305704637029.JavaMail.root@zimbra> <2079625790.196771305711899307.JavaMail.root@zimbra> Message-ID: <20110518115356.GE7320@aluminum.local> On Wed, May 18, 2011 at 09:44:59AM +0000, Robert Virding wrote: } After the supervisor has started a child server won't it then } be running completely unsynchronised with the supervisor? The supervisor starts each child specification in the order provided. Sure, the first child started is up and running on his own before the next ones however in my example the child then calls the supervisor to learn all the child specifications. The supervisor won't answer until the last child is started. In my example the supervisor will have queued requests from the other children when it is finished starting the last child. Try adding a delay in the initialization and you'll see the same result: init([Sup, N]) -> receive after 4000 -> ok end, {ok, #state{sup = Sup, state = init, n = N}, 0}. 1> supervisor:start_link(which_sup, []). Server=1, Siblings=[<0.39.0>,<0.38.0>] Server=2, Siblings=[<0.39.0>,<0.37.0>] Server=3, Siblings=[<0.38.0>,<0.37.0>] {ok,<0.36.0>} } In that case how will a server know that all the other servers have } been started? When their request is handled all initialization is complete. -- -Vance From fred.hebert@REDACTED Wed May 18 13:55:14 2011 From: fred.hebert@REDACTED (=?iso-8859-1?Q?Fr=E9d=E9ric_Trottier-H=E9bert?=) Date: Wed, 18 May 2011 07:55:14 -0400 Subject: [erlang-questions] 'reply-to' header in this mailing list In-Reply-To: References: <20110517142848.GA9263@erix.ericsson.se> <230D6DBF-EE90-475F-A973-DF0E7B71EF19@cs.otago.ac.nz> Message-ID: I personally see a practical side to the current list functionality. Get it wrong and you can re-send your e-mail to the list without any embarrassment. Get it wrong in a list where 'Reply' emails to the list and you might be disclosing personal or private information to the public, only for it to later be indexed by search engines. One clearly has worse non-reversible consequences than the other. My vote is to keep things the way they are right now. -- Fred H?bert http://www.erlang-solutions.com From vances@REDACTED Wed May 18 13:57:16 2011 From: vances@REDACTED (Vance Shipley) Date: Wed, 18 May 2011 17:27:16 +0530 Subject: [erlang-questions] supervisor children's pid In-Reply-To: <20110518083422.GB1762@hanele.lan> References: <20110518044824.GC7320@aluminum.local> <20110518083422.GB1762@hanele.lan> Message-ID: <20110518115713.GF7320@aluminum.local> On Wed, May 18, 2011 at 09:34:22AM +0100, Jachym Holecek wrote: } Nice trick, but there is no guarantee process' siblings will already be } started after some arbitrary timeout -- try this on a heavily loaded } system... it's just not safe. You try it. I already have. } > } is this the best strategy to achieve this? } > } > Yes, use supervisor:which_children/1 to learn the siblings. } } No, if he's using anything other than one_for_all strategy the Pids } he learns this way may become stale in the future. My example demonstrates learning the siblings at startup. Monitoring changes is another question. -- -Vance From vances@REDACTED Wed May 18 14:13:14 2011 From: vances@REDACTED (Vance Shipley) Date: Wed, 18 May 2011 17:43:14 +0530 Subject: [erlang-questions] supervisor started from gen_server In-Reply-To: References: Message-ID: <20110518121242.GG7320@aluminum.local> On Wed, May 18, 2011 at 11:38:50AM +0200, Roberto Ostinelli wrote: } just a quick question: can you think of any case in which starting a } supervisor from a gen_server would actually be a perfectly fit idea? Never. +---------+ | foo_sup | +-+-----+-+ / \ +----------+--+ +--+---------+ | bar_sup_sup | | foo_server | +---+---------+ +------------+ | +----+----+ | bar_sup | +---------+ Start a supervisor for the new dynamic supervisor(s) and use supervisor:start_child/2 from the gen_server to start it. -- -Vance From dmitrii@REDACTED Wed May 18 14:16:30 2011 From: dmitrii@REDACTED (Dmitrii Dimandt) Date: Wed, 18 May 2011 15:16:30 +0300 Subject: [erlang-questions] Erlang Style Guide Message-ID: <5DA19A7D-7A10-4A06-B7F9-7CF1F056E52C@dmitriid.com> Hi all! Is there a more-or-less universally accepted Erlang Style Guide. SImilar to, say, PEP08 (http://www.python.org/dev/peps/pep-0008/). If there isn't, does anyone has a style guide the use? Would you care to share you style guides with the list? Thank you! From raimo+erlang-questions@REDACTED Wed May 18 14:21:03 2011 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Wed, 18 May 2011 14:21:03 +0200 Subject: [erlang-questions] 'reply-to' header in this mailing list In-Reply-To: References: Message-ID: <20110518122103.GB4121@erix.ericsson.se> On Tue, May 17, 2011 at 01:04:58PM +0200, Alexander Krasnukhin wrote: > Hej, > > Why this mailing list doesn't add itself to the 'reply-to' header? I see it > isn't uncommon for subscribers to send message to the author directly > instead of the list. > > I wonder why? 1) This is an old mailing list. It has been around since 1997, which is long before Google et.al started to violate then already accepted mailing list behaviours probably with the intention to unify forum like behaviour with mailing lists. It has always been like this, expect for a short while when I changed mailing list software and accidentally configured the behaviour you ask and the list exploded with dislike. The existing subscribers expect this behaviour. 2) It is according to Internet standards. 3) It lowers the probability of sending privately intended mails to the list. One might argue that it is not proven that the majority of the currently existing subscribers actually want it this way. That is correct, but it is just a few new subscribers asking this question getting little positive response from the existing subscribers. And we all have other things to do than to dig up already worn out arguments in this futile debate. If a large number of old reliable subscribers start voicing the opinion that this Reply-To setting is now a bad idea we might change the setting. Such a controversial change would require a _large_ majority. I anyone tries to start a flamewar about changing the Reply-To setting it will be regarded as off-topic and nonproductive and they will end up ignored or banned. > > -- > Regards, > Alexander > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From raimo+erlang-questions@REDACTED Wed May 18 14:30:26 2011 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Wed, 18 May 2011 14:30:26 +0200 Subject: [erlang-questions] 'reply-to' header in this mailing list In-Reply-To: References: <20110517142848.GA9263@erix.ericsson.se> Message-ID: <20110518123026.GC4121@erix.ericsson.se> On Tue, May 17, 2011 at 05:07:50PM +0200, Alexander Krasnukhin wrote: > Yes, yes. I've got this. People from telecom will always rely on standards > instead of people expectations. Good. Right. Understandable. There are standards and often conflicting standards. We have already made a delibirate choiche of which standards we believe in. There are different people expecting different things. Newcomers to a list should not expect that all oldtimers expect the same as themselves. If this list behaviour feels differently than other list it depends which lists you regard as the other. Many lists today are really Google groups, and they seem to have chosen to violate Internet standards since they are more like a forum, and in forums private messages do not exist. The default setting for both Majordomo and Mailman is to not munge Reply-To, and their documentation discourages changing this. All mailing lists at e.g openbsd.org do not munge Reply-To. -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From dmitrii@REDACTED Wed May 18 14:36:49 2011 From: dmitrii@REDACTED (Dmitrii Dimandt) Date: Wed, 18 May 2011 15:36:49 +0300 Subject: [erlang-questions] 'reply-to' header in this mailing list In-Reply-To: <230D6DBF-EE90-475F-A973-DF0E7B71EF19@cs.otago.ac.nz> References: <20110517142848.GA9263@erix.ericsson.se> <230D6DBF-EE90-475F-A973-DF0E7B71EF19@cs.otago.ac.nz> Message-ID: <16F492DD-EBEE-4FC3-86F6-F6A1D4D6D6F3@dmitriid.com> I'd disagree with you on that. I receive an email from the list. I send my emails to the list. It's one sender and one recepient. So I expect Reply-To to send my email back to the list. Moreover, if you hit "Reply All", you'll end up sending multiple emails to seemingly random people: Right now this email will be sent To: Richard O'Keefe, CC: Alexandr Krasnukhin, Erlang Questions. Both you and Alexandr will end up with two copies of my letter (one sent directly from me and one sent from the mailing list). This is clearly not the behaviour I'd want when I want to reply to a message from the mailing list. The number of recepients varies depending on which email you reply to, but the idea is the same. Instead of sending one email to one recepient (the list) I end up spamming people :) So what do I have do now? I have to delete all the extra emails and move Erlang Questions to the "To:" field. This way I increase the chance that the recepient(s) will also reply to the list and not to me directly. > > On 18/05/2011, at 3:07 AM, Alexander Krasnukhin wrote: > >> Yes, yes. I've got this. People from telecom will always rely on standards instead of people expectations. Good. Right. Understandable. > > That sounds a bit sarcastic. > The thing is that the Erlang mailing list behaves *EXACTLY* the way I expect > a mailing list to work. > I expect "Reply All" to reply to everyone on the list. > I expect "Reply" to go just to the author. > I expect it to work the way mailing lists always used to work. > > The standard in this case is not arbitrary, but part of a coherent > design to ensure a straightforward user experience. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From dmitrii@REDACTED Wed May 18 14:39:31 2011 From: dmitrii@REDACTED (Dmitrii Dimandt) Date: Wed, 18 May 2011 15:39:31 +0300 Subject: [erlang-questions] Erlang Style Guide In-Reply-To: <5DA19A7D-7A10-4A06-B7F9-7CF1F056E52C@dmitriid.com> References: <5DA19A7D-7A10-4A06-B7F9-7CF1F056E52C@dmitriid.com> Message-ID: This is an excellent guide. However, it mostly deals with language constructs and programming habits. It would be nice to complement this with a "writing style" guide that would discuss identation and nesting, naming conventions etc. > What about this? > > http://www.erlang.se/doc/programming_rules.shtml > > On Wed, May 18, 2011 at 2:16 PM, Dmitrii Dimandt wrote: > Hi all! > > Is there a more-or-less universally accepted Erlang Style Guide. SImilar to, say, PEP08 (http://www.python.org/dev/peps/pep-0008/). > > If there isn't, does anyone has a style guide the use? Would you care to share you style guides with the list? > > Thank you! > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > -- > Regards, > Alexander -------------- next part -------------- An HTML attachment was scrubbed... URL: From the.malkolm@REDACTED Wed May 18 14:43:54 2011 From: the.malkolm@REDACTED (Alexander Krasnukhin) Date: Wed, 18 May 2011 14:43:54 +0200 Subject: [erlang-questions] 'reply-to' header in this mailing list In-Reply-To: <20110518123026.GC4121@erix.ericsson.se> References: <20110517142848.GA9263@erix.ericsson.se> <20110518123026.GC4121@erix.ericsson.se> Message-ID: Seriously, I *do* understand your point. It wasn't a sarcasm or a joke. On Wed, May 18, 2011 at 2:30 PM, Raimo Niskanen < raimo+erlang-questions@REDACTED> wrote: > On Tue, May 17, 2011 at 05:07:50PM +0200, Alexander Krasnukhin wrote: > > Yes, yes. I've got this. People from telecom will always rely on > standards > > instead of people expectations. Good. Right. Understandable. > > There are standards and often conflicting standards. We have already > made a delibirate choiche of which standards we believe in. > > There are different people expecting different things. > Newcomers to a list should not expect that all oldtimers > expect the same as themselves. > > If this list behaviour feels differently than other list it > depends which lists you regard as the other. Many lists > today are really Google groups, and they seem to have chosen > to violate Internet standards since they are more like a > forum, and in forums private messages do not exist. > > The default setting for both Majordomo and Mailman is to > not munge Reply-To, and their documentation discourages > changing this. All mailing lists at e.g openbsd.org > do not munge Reply-To. > > > -- > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Regards, Alexander -------------- next part -------------- An HTML attachment was scrubbed... URL: From watson.timothy@REDACTED Wed May 18 14:45:07 2011 From: watson.timothy@REDACTED (Tim Watson) Date: Wed, 18 May 2011 13:45:07 +0100 Subject: [erlang-questions] supervisor children's pid In-Reply-To: References: <20110518044824.GC7320@aluminum.local> <20110518083422.GB1762@hanele.lan> Message-ID: >> >> ?* Run a name resolution server somewhere and have all the children >> ? ?subscribe to it. The server will monitor them and may provide >> ? ?notification facility to announce Pid changes/availability to >> ? ?anyone interested -- this lets you do safe startup of dependent >> ? ?processes. > > probably the best would be then to have a gen_event module for this. this is > a good idea. > wouldn't gproc be useful for this? The keys don't have to matter and you can subscribe based on a match/wildcard. From erlang@REDACTED Wed May 18 15:02:00 2011 From: erlang@REDACTED (Joe Armstrong) Date: Wed, 18 May 2011 15:02:00 +0200 Subject: [erlang-questions] Erlang Style Guide In-Reply-To: References: <5DA19A7D-7A10-4A06-B7F9-7CF1F056E52C@dmitriid.com> Message-ID: On Wed, May 18, 2011 at 2:39 PM, Dmitrii Dimandt wrote: > This is an excellent guide. However, it mostly deals with language > constructs and programming habits. It would be nice to complement this with > a "writing style" guide that would discuss identation and nesting, naming > conventions etc. > > > Where to put punctuation, naming etc. is a matter that is discussed with religious fervor - nobody agrees here at all ... /Joe > > What about this? > > http://www.erlang.se/doc/programming_rules.shtml > > On Wed, May 18, 2011 at 2:16 PM, Dmitrii Dimandt > wrote: > >> Hi all! >> >> >> Is there a more-or-less universally accepted Erlang Style Guide. SImilar >> to, say, PEP08 (http://www.python.org/dev/peps/pep-0008/). >> >> If there isn't, does anyone has a style guide the use? Would you care to >> share you style guides with the list? >> >> Thank you! >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > > > -- > Regards, > Alexander > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mihai@REDACTED Wed May 18 15:07:11 2011 From: mihai@REDACTED (Mihai Balea) Date: Wed, 18 May 2011 09:07:11 -0400 Subject: [erlang-questions] supervisor children's pid In-Reply-To: References: <20110518044824.GC7320@aluminum.local> <20110518083422.GB1762@hanele.lan> Message-ID: <680E7155-4C1B-45E4-A0F6-283DD7A459EE@hates.ms> On May 18, 2011, at 8:45 AM, Tim Watson wrote: > > wouldn't gproc be useful for this? The keys don't have to matter and > you can subscribe based on a match/wildcard. +1 Although I have to ask why is it really necessary to have children know (dynamically) the pids of all other children.... maybe the system can be re-designed to work around this requirement? Mihai -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.eugene.turner@REDACTED Wed May 18 15:29:39 2011 From: michael.eugene.turner@REDACTED (Michael Turner) Date: Wed, 18 May 2011 22:29:39 +0900 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: Message-ID: It's just been pointed out to me (in a possibly *unintentionally* private e-mail) that this topic was already taken up on a recent thread: http://erlang.org/pipermail/erlang-questions/2011-May/058323.html I don't really understand one of the objections: that newbies would find it strange. When I started learning Erlang, even with some experience in lisp and prolog, I found *lots* of things strange. And yes, I understand that function clauses were borrowed from prolog. But an influence is not a stricture, especially when that influence is only partial, as it is here -- and maybe prolog wasn't doing it right either? The better way to evaluate newbie-friendliness of the proposed syntactic change is to do it *scientifically*: teach some newbies both ways of writing function clauses, then see how well they do in timed code-comprehension tests where the only difference is the proposed change in syntax. I predict they'd actually have an easier time with what I propose, or at least do just as well. -michael On Wed, May 18, 2011 at 6:16 PM, Michael Turner < michael.eugene.turner@REDACTED> wrote: > I can say > > fun (1)->2; > (2)->1 > end > > but, oddly, I can't define a named function in the analogous way, e.g.: > > factorial > (1) -> 1; > (N) -> N*factorial(N-1). > > gives me a syntax error. I find the latter more readable than > > factorial(1) -> 1; > factorial(2) -> N*fact(N-1). > > It's also less to type and to read, which is consistent with the DRY > principle ("Don't Repeat Yourself"). And it lends itself to reading a > function definition as a set of cases. I think for Erlang newbies, it should > therefore would be preferred: it helps underscore the pattern-matching style > of Erlang function invocation. > > It also looks a *little* bit more like the mathematical convention for > defining these sorts of functions, where you have "f(x) = ", centered > vertically to the left of a big left "{" that (left-)encloses the list of > expression/parameter-condition pairs in a two-column format, e.g., > > http://cnx.org/content/m29517/latest/Picture%2047.png > > So there's a (weak) argument from the Principle of Least Surprise here as > well. > > It seems to me that, if anything, this requires only a *simplification* of > the Erlang parser. That leaves only one obvious objection: would any > existing code break if Erlang syntax were altered to allow this? > > -michael turner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmercer@REDACTED Wed May 18 15:56:48 2011 From: dmercer@REDACTED (David Mercer) Date: Wed, 18 May 2011 08:56:48 -0500 Subject: [erlang-questions] Erlang Style Guide In-Reply-To: References: <5DA19A7D-7A10-4A06-B7F9-7CF1F056E52C@dmitriid.com> Message-ID: <007501cc1563$701fce60$505f6b20$@com> I daresay, if ROK would publish his standards, I'd probably follow them. He's the guy who puts punctuation at the beginning of a lot of lines. The way it is now, I just go with what looks good (which means punctuation at the end of the line), because I can't be bothered coming up with rules to follow, but I'm pretty sure ROK has in his head some self-consistent system that makes sense and makes coding easier. Actually, I'd probably follow anyone's formatting rules if someone would publish some. Maybe I should. Cheers, DBM From: erlang-questions-bounces@REDACTED [mailto:erlang-questions-bounces@REDACTED] On Behalf Of Joe Armstrong Sent: Wednesday, May 18, 2011 8:02 AM To: Dmitrii Dimandt Cc: Erlang Questions Subject: Re: [erlang-questions] Erlang Style Guide On Wed, May 18, 2011 at 2:39 PM, Dmitrii Dimandt wrote: This is an excellent guide. However, it mostly deals with language constructs and programming habits. It would be nice to complement this with a "writing style" guide that would discuss identation and nesting, naming conventions etc. Where to put punctuation, naming etc. is a matter that is discussed with religious fervor - nobody agrees here at all ... /Joe What about this? http://www.erlang.se/doc/programming_rules.shtml On Wed, May 18, 2011 at 2:16 PM, Dmitrii Dimandt wrote: Hi all! Is there a more-or-less universally accepted Erlang Style Guide. SImilar to, say, PEP08 (http://www.python.org/dev/peps/pep-0008/). If there isn't, does anyone has a style guide the use? Would you care to share you style guides with the list? Thank you! _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -- Regards, Alexander _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.virding@REDACTED Wed May 18 16:06:37 2011 From: robert.virding@REDACTED (Robert Virding) Date: Wed, 18 May 2011 14:06:37 +0000 (GMT) Subject: [erlang-questions] 'reply-to' header in this mailing list In-Reply-To: <688144131.198481305727593991.JavaMail.root@zimbra> Message-ID: <600128661.198501305727597470.JavaMail.root@zimbra> How about we completely side-step the whole issue and re-structure the various erlang mailing lists a forum instead? And by choosing one of the common and free forum packages we will automatically get a standard (in the sense of being common and much used) behaviour. This is also a serious suggestion. Robert ----- "Alexander Krasnukhin" wrote: > Seriously, I do understand your point. It wasn't a sarcasm or a joke. > > > On Wed, May 18, 2011 at 2:30 PM, Raimo Niskanen < raimo+erlang-questions@REDACTED > wrote: > > On Tue, May 17, 2011 at 05:07:50PM +0200, Alexander Krasnukhin wrote: > > Yes, yes. I've got this. People from telecom will always rely on standards > > instead of people expectations. Good. Right. Understandable. > > There are standards and often conflicting standards. We have already > made a delibirate choiche of which standards we believe in. > > There are different people expecting different things. > Newcomers to a list should not expect that all oldtimers > expect the same as themselves. > > If this list behaviour feels differently than other list it > depends which lists you regard as the other. Many lists > today are really Google groups, and they seem to have chosen > to violate Internet standards since they are more like a > forum, and in forums private messages do not exist. > > The default setting for both Majordomo and Mailman is to > not munge Reply-To, and their documentation discourages > changing this. All mailing lists at e.g openbsd.org > do not munge Reply-To. > > > -- > > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > -- > Regards, > Alexander > > > _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From jack@REDACTED Wed May 18 16:11:17 2011 From: jack@REDACTED (Jack Moffitt) Date: Wed, 18 May 2011 08:11:17 -0600 Subject: [erlang-questions] 'reply-to' header in this mailing list In-Reply-To: <600128661.198501305727597470.JavaMail.root@zimbra> References: <688144131.198481305727593991.JavaMail.root@zimbra> <600128661.198501305727597470.JavaMail.root@zimbra> Message-ID: > How about we completely side-step the whole issue and re-structure the > various erlang mailing lists a forum instead? And by choosing one of the > common and free forum packages we will automatically get a standard (in the > sense of being common and much used) behaviour. I really dislike forums. it's very easy for me to rapidly read and reply to any topics on a mailing list, but with a forum I have to 1) visit a particular page 2) manually click around. I much prefer having things in an email client which is optimized for the job. The only advantage to forums in my opinion is that the archives tend to be much better than mailing list archives. jack. From jack@REDACTED Wed May 18 16:16:08 2011 From: jack@REDACTED (Jack Moffitt) Date: Wed, 18 May 2011 08:16:08 -0600 Subject: [erlang-questions] Erlang Style Guide In-Reply-To: <007501cc1563$701fce60$505f6b20$@com> References: <5DA19A7D-7A10-4A06-B7F9-7CF1F056E52C@dmitriid.com> <007501cc1563$701fce60$505f6b20$@com> Message-ID: > I daresay, if ROK would publish his standards, I?d probably follow them. > He?s the guy who puts punctuation at the beginning of a lot of lines.? The > way it is now, I just go with what looks good (which means punctuation at > the end of the line), because I can?t be bothered coming up with rules to > follow, but I?m pretty sure ROK has in his head some self-consistent system > that makes sense and makes coding easier. +1 for people publishing these. I don't everyone will agree on a single set, but having a few of these to point to would help I think. Is there not an OTP coding guidelines that OTP contributors must follow? Currently I let the Emacs mode decide what is best, but I often disagree with it. I've been considering changing forms like: Something = case mod:func(Args) of foo -> ok; bar -> not_ok end, to: Something = case mod:func(Args) of foo -> ok; bar -> not_ok end, which is more what I'm used to from JavaScript. jack. From ivan@REDACTED Wed May 18 16:18:01 2011 From: ivan@REDACTED (Ivan Uemlianin) Date: Wed, 18 May 2011 15:18:01 +0100 Subject: [erlang-questions] 'reply-to' header in this mailing list In-Reply-To: References: <688144131.198481305727593991.JavaMail.root@zimbra> <600128661.198501305727597470.JavaMail.root@zimbra> Message-ID: <4DD3D519.4000401@llaisdy.com> On 18/05/2011 15:11, Jack Moffitt wrote: > I really dislike forums. it's very easy for me to rapidly read and > reply to any topics on a mailing list, but with a forum I have to 1) > visit a particular page 2) manually click around. I much prefer having > things in an email client which is optimized for the job. +1 -- ============================================================ Ivan A. Uemlianin Speech Technology Research and Development ivan@REDACTED www.llaisdy.com llaisdy.wordpress.com www.linkedin.com/in/ivanuemlianin "Froh, froh! Wie seine Sonnen, seine Sonnen fliegen" (Schiller, Beethoven) ============================================================ From michael.eugene.turner@REDACTED Wed May 18 16:18:36 2011 From: michael.eugene.turner@REDACTED (Michael Turner) Date: Wed, 18 May 2011 23:18:36 +0900 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: Message-ID: Another objection raised against this syntax change is that all functional languages violate DRY in this manner, so it's OK if Erlang does it too. This is a Principle of Least Surprise argument, and not bad as far as it goes. But how far does it go? Erlang will have a better chance of greater success and survival if you consider your recruitment base to be the overwhelming majority of programmers. And from what I can tell, http://www.langpop.com the overwhelming majority of programmers have no experience to speak of, when it comes to functional programming languages. Appealing to the "cross-training" benefit of coming from other FP languages seems like a pretty weak argument. Especially since all I'm asking for here is syntactic consistency *within* Erlang -- a PLoS argument in itself. Richard O'Keefe suggests that the syntactic consistency goal is better met by allowing a kind of limited-scope special-case fun name, permitting, e.g. Fact = fun F(0) -> 1; F(N) -> N*F(N-1) end. I could get behind that too, but I don't follow his reasoning from syntactic consistency, which is apparently that an unnamed fun has a name, it's just the degenerate case of a name. It's really there. We just can't see it. Hm, really? If that were true in Erlang as it stands, shouldn't I be able to write it this way? Fact = fun (0) -> 1; (N) -> N*''(N-1) end. Looks like it's not quite that simple. It compiles, but it doesn't know what module to look in for '', when it comes time to execute. In the shell, I get an error indicating that it tried to resolve ''/1 as a shell command. Even if I put it in a .erl file and compile it, there's no obvious way to tell the compiler what module to look in. ?MODULE:'' doesn't work. Nor does '':'', which I tried just for the hell of it. What Richard's suggesting appears to require a rigorous re-think of how scopes are defined in Erlang. What I'm suggesting amounts to simply asking the compiler to do some of your tedious keying for you. -michael turner On Wed, May 18, 2011 at 6:16 PM, Michael Turner < michael.eugene.turner@REDACTED> wrote: > I can say > > fun (1)->2; > (2)->1 > end > > but, oddly, I can't define a named function in the analogous way, e.g.: > > factorial > (1) -> 1; > (N) -> N*factorial(N-1). > > gives me a syntax error. I find the latter more readable than > > factorial(1) -> 1; > factorial(2) -> N*fact(N-1). > > It's also less to type and to read, which is consistent with the DRY > principle ("Don't Repeat Yourself"). And it lends itself to reading a > function definition as a set of cases. I think for Erlang newbies, it should > therefore would be preferred: it helps underscore the pattern-matching style > of Erlang function invocation. > > It also looks a *little* bit more like the mathematical convention for > defining these sorts of functions, where you have "f(x) = ", centered > vertically to the left of a big left "{" that (left-)encloses the list of > expression/parameter-condition pairs in a two-column format, e.g., > > http://cnx.org/content/m29517/latest/Picture%2047.png > > So there's a (weak) argument from the Principle of Least Surprise here as > well. > > It seems to me that, if anything, this requires only a *simplification* of > the Erlang parser. That leaves only one obvious objection: would any > existing code break if Erlang syntax were altered to allow this? > > -michael turner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ixmatus@REDACTED Wed May 18 17:05:20 2011 From: ixmatus@REDACTED (Parnell Springmeyer) Date: Wed, 18 May 2011 08:05:20 -0700 Subject: [erlang-questions] 'reply-to' header in this mailing list In-Reply-To: (Michael Turner's message of "Wed, 18 May 2011 14:35:52 +0900") References: <20110517142848.GA9263@erix.ericsson.se> <230D6DBF-EE90-475F-A973-DF0E7B71EF19@cs.otago.ac.nz> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Um, isn't it client specific and not list specific? Every list I've been a part of has a broad reply. So if I send a reply to erlang-questions@REDACTED with the "Re: [erlang-questions] 'reply-to' header in this mailing list" subject it goes to everyone on that list. If I do a wide reply (Emacs: Shft-f) it will send the reply message to the specific person I'm replying to /and/ it will send it to the list (as is happening with this email). I can also send just the reply to the list, or just a reply to the specific person. They are just different commands. As it stands, the mailing list does exactly what I expect it to. Maybe your software is what's not living up to your familiarity/intuitive standards? Michael Turner writes: > Does anyone have any statistics on this question? That is, what > percentage of mailing lists "do it wrong"? It's counterintuitive to me > that ?a "reply" on this mailing list is only to the individual. "Reply" > is "Reply to the list" on every other mailing list I'm currently on, > and on almost every mailing list I can remember being on. But perhaps > my lifetime mailing list membership doesn't approach statistical > significance. > > Although it may get me accused of "blindly following the herd," let me > assert it anyway: arguments from "intuition" in commonly used software > interfaces only work when you have statistically significant user > support for them, not some purely formal, rule-based argument for your > *personal* intuition. What's "intuitive" to one person may be > counterintuitive to many. As pointed out long ago, "intuitive equals > familiar": > > ??http://www.asktog.com/papers/raskinintuit.html > > And, as pointed out even longer ago, "a foolish consistency is the > hobgoblin of small minds." (Emerson.) > > Perhaps to some people, a mailing list is like a noticeboard in a > mostly-empty hallway. My mental model of a mailing list corresponds > more closely to a conversation in a classroom. When you reply to an > open question or comment in such a context, you cannot help but be > heard by more than one person; most likely you'll be heard by everyone > in the room. You actually have to make a special effort (i.e., lean > over and whisper in an ear, or pass a note) to be sure that your reply > is private. I think this corresponds pretty closely to the intuition of > the average mailing list user. But erlangeurs may be different, I don't > know. > > -michael turner > > On Wed, May 18, 2011 at 8:45 AM, Richard O'Keefe > wrote: > > On 18/05/2011, at 3:07 AM, Alexander Krasnukhin wrote: > > > Yes, yes. I've got this. People from telecom will always rely on > standards instead of people expectations. Good. Right. > Understandable. > > That sounds a bit sarcastic. > The thing is that the Erlang mailing list behaves *EXACTLY* the way > I expect > a mailing list to work. > I expect "Reply All" to reply to everyone on the list. > I expect "Reply" to go just to the author. > I expect it to work the way mailing lists always used to work. > > The standard in this case is not arbitrary, but part of a coherent > design to ensure a straightforward user experience. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions - -- Parnell "ixmatus" Springmeyer (http://ixmat.us) -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJN0+AwAAoJEPvtlbpI1POL1XsIAKqeSs9CILOT9zgaV74S89Ij kWSsf70Kh+MQeG0Q0L84YO1YvZ9vKcPiN3sShzGuVHddIPDJESOSJT5v0wNb9T6I LUU1cY+QMkoOBE8NUCQV6xcS6go5SjF0/gWbdWTH/uvRy0LVRIBnsbM+nFCPmLCr cAlNB7ZOi8T1VGZk0jIGoknolzrAL8BuHua5KpZcJns5D8xn0sBOiZZEJzIZTGRG MJ1FYPDp4V61QI+vrUlZxb2OqHej60yhG9kzcyzlAd3Np6vCscFB0hZ0iQzAVcVi ruT+Z5xD8+F3YcxhafIENGJTWetsNzgVO6khVkdVBaw5AYc97/yquNqLOfLokME= =4PpW -----END PGP SIGNATURE----- From ixmatus@REDACTED Wed May 18 17:11:27 2011 From: ixmatus@REDACTED (Parnell Springmeyer) Date: Wed, 18 May 2011 08:11:27 -0700 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: (Michael Turner's message of "Wed, 18 May 2011 18:16:27 +0900") References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 You're being pedantic dude. I'm sure Joe Armstrong and the other programmers that designed and work on Erlang are acutely aware of DRY, PoLS, and a whole bunch of others. Personally, I think it is a feature to state the function name when defining another function clause. some_func(X, Y) -> %% Long bit of code ...; some_func(X, []) -> %% More code .... Without it, scanning the source could get confusing. Michael Turner writes: > I can say > > ? ?fun (1)->2; > ? ? ? ? (2)->1 > ? ?end > > but, oddly, I can't define a named function in the analogous way, e.g.: > > ? ?factorial > ? ? ?(1) -> 1; > ? ? ?(N) -> N*factorial(N-1). > > gives me a syntax error. I find the latter more readable than > > ? ?factorial(1) -> 1; > ? ?factorial(2) -> N*fact(N-1). > > It's also less to type and to read, which is consistent with the DRY > principle ("Don't Repeat Yourself"). ?And it lends itself to reading a > function definition as a set of cases. I think for Erlang newbies, it > should therefore would be preferred: it helps underscore the > pattern-matching style of Erlang function invocation. > > It also looks a *little* bit more like the mathematical convention for > defining these sorts of functions, where you have "f(x) = ", centered > vertically to the left of a big left "{" that (left-)encloses the list > of expression/parameter-condition pairs in a two-column format, e.g., > > ?http://cnx.org/content/m29517/latest/Picture%2047.png > > So there's a (weak) argument from the Principle of Least Surprise here > as well. > > It seems to me that, if anything, this requires only a *simplification* > of the Erlang parser. That leaves only one obvious objection: would any > existing code break if Erlang syntax were altered to allow this? > > -michael turner > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions - -- Parnell "ixmatus" Springmeyer (http://ixmat.us) -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJN0+GfAAoJEPvtlbpI1POLEMkH/3TKrH5uCapUy+jM2V7+JP43 Fn8EEJIgkuGHd+t1Jp2BI190Yyl+hO1hlarQJzDulGWBdYMtsxIGJ32Za9rJrSyo C+nzfDpC5cKrLXXlk4vFq+GphnKOoOffQ7FCqQvElL89GBXxt7cvPCjk6X04BuYI MhQYidxOozerdvNkH1iw9uC61zVhz0ahPqwuMbyzCg71BjLYo8NR+qYpqtiTMHjx nXar6vcjzsrEQzi5Ul5hWjrgzQQgecFOeeZ5bQjTzhKfHMpUk1beI5rQuYxpuvVd 8kA1YiOU5mfQqoqA+ZKpoG598Isp1vnTc+DQznJC9GbE4mgUWNO5n4J51U2OR5U= =ypYB -----END PGP SIGNATURE----- From ixmatus@REDACTED Wed May 18 17:16:34 2011 From: ixmatus@REDACTED (Parnell Springmeyer) Date: Wed, 18 May 2011 08:16:34 -0700 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: (Michael Turner's message of "Wed, 18 May 2011 22:29:39 +0900") References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Catering directly to the lowest common denominator is *not* a good strategy. People should stop saying this: "We need to change feature X to for reason Y for n00bs" and start saying this: "We need to write more engaging documentation and have better idiomatic use case examples so n00bs can /learn/". It's easier to educate them than to not. Sure, learning Erlang is a rough ride for your first year - but once you grok it, you have it for life. I would actually think they *wouldn't* have an easier time with that sort of syntactic change because now you have to find that hidden set of parentheses in a possible sea of code. See my previous email. It's a nice idea in theory for small examples like factorial - but when you have large functions that have multiple clauses, it is SOOOOOO nice being able to scan down the left side of your editor window and see all of those function names. Michael Turner writes: > It's just been pointed out to me (in a possibly *unintentionally* > private e-mail) that this topic was already taken up on a recent > thread: > > ??http://erlang.org/pipermail/erlang-questions/2011-May/058323.html > > I don't really understand one of the objections: that newbies would > find it strange. When I started learning Erlang, even with some > experience in lisp and prolog, I found *lots* of things strange. > > And yes, I understand that function clauses were borrowed from prolog. > But an influence is not a stricture, especially when that influence is > only partial, as it is here -- and maybe prolog wasn't doing it right > either? > > The better way to evaluate newbie-friendliness of the proposed > syntactic change is to do it *scientifically*: teach some newbies both > ways of writing function clauses, then see how well they do in timed > code-comprehension tests where the only difference is the proposed > change in syntax. I predict they'd actually have an easier time with > what I propose, or at least do just as well. > > -michael > > On Wed, May 18, 2011 at 6:16 PM, Michael Turner < > michael.eugene.turner@REDACTED> wrote: > > I can say > > ? ?fun (1)->2; > ? ? ? ? (2)->1 > ? ?end > > but, oddly, I can't define a named function in the analogous way, > e.g.: > > ? ?factorial > ? ? ?(1) -> 1; > ? ? ?(N) -> N*factorial(N-1). > > gives me a syntax error. I find the latter more readable than > > ? ?factorial(1) -> 1; > ? ?factorial(2) -> N*fact(N-1). > > It's also less to type and to read, which is consistent with the > DRY principle ("Don't Repeat Yourself"). ?And it lends itself to > reading a function definition as a set of cases. I think for Erlang > newbies, it should therefore would be preferred: it helps > underscore the pattern-matching style of Erlang function > invocation. > > It also looks a *little* bit more like the mathematical convention > for defining these sorts of functions, where you have "f(x) = ", > centered vertically to the left of a big left "{" that (left-) > encloses the list of expression/parameter-condition pairs in a > two-column format, e.g., > > ?http://cnx.org/content/m29517/latest/Picture%2047.png > > So there's a (weak) argument from the Principle of Least Surprise > here as well. > > It seems to me that, if anything, this requires only a > *simplification* of the Erlang parser. That leaves only one obvious > objection: would any existing code break if Erlang syntax were > altered to allow this? > > -michael turner > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions - -- Parnell "ixmatus" Springmeyer (http://ixmat.us) -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJN0+LTAAoJEPvtlbpI1POLw1IH+QHYn/PuxcxZz6Xp6yzVuhnM rPNkpp/kWpub2EBxo0qfyt/xhXE/FCdfHfgTy6T0mOXbuXx8vRRqVSQHP4OXwWSr 5NEnlavUQjIGtUjI8FX+ImSqNOWmvlT0RtMpwP7tuvFEiDpcc5XFf6+ba1ktJoK5 cNKNm1EFp6qLCN5y33Nrd/OavtTJf4o9nv/08gxpwRU3tIoee9Lh1uJTpmJ8EPh3 zfYRZ/wIR/7xMFIK40X+7YMyAEzmwy9TDM7RLAgwLrqMjbuphfRq0BDeLUVVRGhe SMPS41QUjmxHkMY7W4t6S6KJy2BGey7pYeXNXjBbOhabiBknvHbl/Xd/APAU5/E= =DpFL -----END PGP SIGNATURE----- From ixmatus@REDACTED Wed May 18 17:29:48 2011 From: ixmatus@REDACTED (Parnell Springmeyer) Date: Wed, 18 May 2011 08:29:48 -0700 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: (Michael Turner's message of "Wed, 18 May 2011 23:18:36 +0900") References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry, but Erlang doesn't *need* a better chance of survival. This language is not just growing, it's booming. Changing core language features that are solid, well thought out, and non-harmful (in other words, they are, FEATURES) to make it more "adoptable" is a lot like someone saying, "you have to quit that quirky smile so other people will like you more." Sometimes, yes, there are features in a language that could use refinement - but many times, in a mature language, the ratio between need and usefulness in refining a feature further, drops significantly. Instead of changing something that is solid, educate the people that have a hard time grasping it, build killer example applications that exhibit the quirky style and idioms to a T - people /will/ follow it, almost to a religious end. That's actually what I like about Erlang the most, the documentation has so many gems in it like the efficiency guide (where many common idioms are expressed with clear DO and DON'T DO examples) and style guide. RE: syntactic consistency: Erlang's syntax *IS* consistent - it's more consistent than many languages I've touched. Is Erlang easy for a Perl programmer? I bet not, and Perl's syntax is less consistent than Erlang's is in my opinion. The issue you are attempting to get at is (again) an educational and experience one, not something that is inherently wrong with the language or its expression itself. I'm actually baffled by the efforts people are putting into different Erlang VM frontends that look like Ruby or Python. Good on them for exercising the freedom of open source but /why/? Erlang's syntax is almost beautiful to me now after using it, it's so well suited for what Erlang is good at! Erlang isn't that great for general purpose programming - you use Python, Ruby, C, D, etc... for stuff like that. Erlang is great at fault tolerance, easy parallelism (which isn't easy!), and hot code loading. Features that are so difficult to do in the traditional imperative environment that (to date) I have not seen a single implementation of any one of those features that even approaches the completeness of Erlang's. Michael Turner writes: > Another objection raised against this syntax change is that all > functional languages violate DRY in this manner, so it's OK if Erlang > does it too. This is a Principle of Least Surprise argument, and not > bad as far as it goes. But how far does it go? > > Erlang will have a better chance of greater success and survival if you > consider your recruitment base to be?the overwhelming majority of > programmers. And from what I can tell, > > ? http://www.langpop.com > > the overwhelming majority of programmers have no experience to speak > of, when it comes to functional programming languages. Appealing to the > "cross-training" benefit of coming from other FP languages seems like a > pretty weak argument. Especially since all I'm asking for here is > syntactic consistency *within* Erlang -- a PLoS argument in itself. > > Richard O'Keefe suggests that the syntactic consistency goal is better > met by allowing a kind of limited-scope special-case fun name, > permitting, e.g. > > ? Fact = fun F(0) -> 1; F(N) -> N*F(N-1) end. > > I could get behind that too, but I don't follow his reasoning?from > syntactic consistency, which is apparently that an unnamed fun has a > name, it's just the degenerate case of a name. ?It's really there. We > just can't see it. Hm, really? If that were true in Erlang as it > stands, shouldn't I be able to write it this way? > > ? Fact = fun (0) -> 1; (N) -> N*''(N-1) end. > > Looks like it's not quite that simple. It compiles, but it doesn't know > what module to look in for '', when it comes time to execute. In the > shell, I get an error indicating that it tried to resolve ''/1 as a > shell command. Even if I put it in a .erl file and compile it, there's > no obvious way to tell the compiler what module to look in. ?MODULE:'' > doesn't work. Nor does '':'', which I tried just for the hell of it. > > What Richard's suggesting appears to require a rigorous re-think of how > scopes are defined in Erlang. What I'm suggesting amounts to simply > asking the compiler to do some of your tedious keying for you. > > -michael turner > ? > > On Wed, May 18, 2011 at 6:16 PM, Michael Turner < > michael.eugene.turner@REDACTED> wrote: > > I can say > > ? ?fun (1)->2; > ? ? ? ? (2)->1 > ? ?end > > but, oddly, I can't define a named function in the analogous way, > e.g.: > > ? ?factorial > ? ? ?(1) -> 1; > ? ? ?(N) -> N*factorial(N-1). > > gives me a syntax error. I find the latter more readable than > > ? ?factorial(1) -> 1; > ? ?factorial(2) -> N*fact(N-1). > > It's also less to type and to read, which is consistent with the > DRY principle ("Don't Repeat Yourself"). ?And it lends itself to > reading a function definition as a set of cases. I think for Erlang > newbies, it should therefore would be preferred: it helps > underscore the pattern-matching style of Erlang function > invocation. > > It also looks a *little* bit more like the mathematical convention > for defining these sorts of functions, where you have "f(x) = ", > centered vertically to the left of a big left "{" that (left-) > encloses the list of expression/parameter-condition pairs in a > two-column format, e.g., > > ?http://cnx.org/content/m29517/latest/Picture%2047.png > > So there's a (weak) argument from the Principle of Least Surprise > here as well. > > It seems to me that, if anything, this requires only a > *simplification* of the Erlang parser. That leaves only one obvious > objection: would any existing code break if Erlang syntax were > altered to allow this? > > -michael turner > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions - -- Parnell "ixmatus" Springmeyer (http://ixmat.us) -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJN0+XsAAoJEPvtlbpI1POLEXEIAJrjAGVTkveBi5/akYNMjBEX 8wI9twatnXh8sfg2ohGKr3P1hj4jTr9ARrG5wiB9OCArRkBymnjFeY5g2dkBDOhN aN722l+yDPpUewAM58m0dDoDHjrHXvxF1MJejQJGhQ+Nr9fM+7G+4QIrCN9RvX1S QTAS+OqOnl8lsS98yvUiXXLB5ehdHcR46Ix6Sq7UwSvqaOKZMoPrzkTtW3VyS5kf i/uGbPZ1I3KQJYRShk2QlLis/tpXGtLDnYc1E5uADqeClDXy5Au6LWpNqUjNIiWw h8I2emcBq5Ur7nivNUYgnVMjg+0qTkQOtttPpOJ25xIYv07L+eMfXneb5nRx4hc= =GGPU -----END PGP SIGNATURE----- From ixmatus@REDACTED Wed May 18 17:31:42 2011 From: ixmatus@REDACTED (Parnell Springmeyer) Date: Wed, 18 May 2011 08:31:42 -0700 Subject: [erlang-questions] Erlang Style Guide In-Reply-To: (Dmitrii Dimandt's message of "Wed, 18 May 2011 15:39:31 +0300") References: <5DA19A7D-7A10-4A06-B7F9-7CF1F056E52C@dmitriid.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It isn't exactly a writing style guide but I did find the Efficiency Guide extremely useful for learning the common Erlang idioms early on in my learning curve: http://www.erlang.org/doc/efficiency_guide/introduction.html Dmitrii Dimandt writes: > This is an excellent guide. However, it mostly deals with language > constructs and programming habits. It would be nice to complement this > with a "writing style" guide that would discuss identation and nesting, > naming conventions etc. > > What about this? > > http://www.erlang.se/doc/programming_rules.shtml > > On Wed, May 18, 2011 at 2:16 PM, Dmitrii Dimandt < > dmitrii@REDACTED> wrote: > > Hi all! > > Is there a more-or-less universally accepted Erlang Style > Guide. SImilar to, say, PEP08 (http://www.python.org/dev/peps/ > pep-0008/). > > If there isn't, does anyone has a style guide the use? Would > you care to share you style guides with the list? > > Thank you! > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- > Regards, > Alexander > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions - -- Parnell "ixmatus" Springmeyer (http://ixmat.us) -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJN0+ZeAAoJEPvtlbpI1POLsRcH/2F6bqInr7RjVW32i9EEEmW3 TYjr/cLGN1ZgJrTqbiujZEvS9xr6ZfXYln8PmziWjLRl8DWuexNguEdegi9keDFA spTfJzQ3YIkb4oxCv6LlMp/5oNZaLlL/12VfF0rC1cSa7BO97JjpNSjJOSdMpfJF Sz62d/1qKOuojqxEZYfh31nkLFoVf+b5N0gJw/8DCnSd/ZD+knPo2CeflNYSFKDF eyBiP/RyRk1bI+T1T+tsCC08ipA02sQm4vllITMM21smeQO8FbYAV25xEOtKr7Ng Uz6deQl8tbn7QD7j0pQhAYseuT234Kl/zhp3wN1pqMtiqA0SSz7bqPU5byHKMPE= =O2I1 -----END PGP SIGNATURE----- From olopierpa@REDACTED Wed May 18 17:32:21 2011 From: olopierpa@REDACTED (Pierpaolo Bernardi) Date: Wed, 18 May 2011 17:32:21 +0200 Subject: [erlang-questions] 'reply-to' header in this mailing list In-Reply-To: <4DD3D519.4000401@llaisdy.com> References: <688144131.198481305727593991.JavaMail.root@zimbra> <600128661.198501305727597470.JavaMail.root@zimbra> <4DD3D519.4000401@llaisdy.com> Message-ID: On Wed, May 18, 2011 at 16:18, Ivan Uemlianin wrote: > On 18/05/2011 15:11, Jack Moffitt wrote: >> >> I really dislike forums. it's very easy for me to rapidly read and >> reply to any topics on a mailing list, but with a forum I have to 1) >> visit a particular page 2) manually click around. I much prefer having >> things in an email client which is optimized for the job. > > +1 +1 From michael.eugene.turner@REDACTED Wed May 18 17:46:49 2011 From: michael.eugene.turner@REDACTED (Michael Turner) Date: Thu, 19 May 2011 00:46:49 +0900 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: Message-ID: "You're being pedantic dude." If I argued only from syntactic consistency, you'd have a point. Frankly, I don't really care about syntactic consistency, if it doesn't get me something. Having to type less gets me something. Having more readable code gets me something. Those are practical considerations, not mere pedantic ones. Dude. What you have as some_func(X, Y) -> %% Long bit of code ...; some_func(X, []) -> %% More code could, as I proposed above, also be written some_func (X,Y) -> %% long bit of code ...; (X,[]) -> %% More code .... Why is this less readable to you? You could answer, "Because it's not what I'm used to seeing in Erlang programs," but that begs the question. If people were more used to seeing the latter -- because making Erlang syntactically more self-consistent made it possible -- that argument wouldn't have much force -- except as an argument from pure conservatism. And this is entirely apart from "long bit of code" being a classic Smell anyway: http://www.soberit.hut.fi/mmantyla/BadCodeSmellsTaxonomy.htm -michael turner On Thu, May 19, 2011 at 12:11 AM, Parnell Springmeyer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > You're being pedantic dude. I'm sure Joe Armstrong and the other > programmers that designed and work on Erlang are acutely aware of DRY, > PoLS, and a whole bunch of others. > > Personally, I think it is a feature to state the function name when > defining another function clause. > > some_func(X, Y) -> > %% Long bit of code > ...; > some_func(X, []) -> > %% More code > .... > > Without it, scanning the source could get confusing. > > Michael Turner writes: > > > I can say > > > > fun (1)->2; > > (2)->1 > > end > > > > but, oddly, I can't define a named function in the analogous way, e.g.: > > > > factorial > > (1) -> 1; > > (N) -> N*factorial(N-1). > > > > gives me a syntax error. I find the latter more readable than > > > > factorial(1) -> 1; > > factorial(2) -> N*fact(N-1). > > > > It's also less to type and to read, which is consistent with the DRY > > principle ("Don't Repeat Yourself"). And it lends itself to reading a > > function definition as a set of cases. I think for Erlang newbies, it > > should therefore would be preferred: it helps underscore the > > pattern-matching style of Erlang function invocation. > > > > It also looks a *little* bit more like the mathematical convention for > > defining these sorts of functions, where you have "f(x) = ", centered > > vertically to the left of a big left "{" that (left-)encloses the list > > of expression/parameter-condition pairs in a two-column format, e.g., > > > > http://cnx.org/content/m29517/latest/Picture%2047.png > > > > So there's a (weak) argument from the Principle of Least Surprise here > > as well. > > > > It seems to me that, if anything, this requires only a *simplification* > > of the Erlang parser. That leaves only one obvious objection: would any > > existing code break if Erlang syntax were altered to allow this? > > > > -michael turner > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > - -- > Parnell "ixmatus" Springmeyer (http://ixmat.us) > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > > iQEcBAEBAgAGBQJN0+GfAAoJEPvtlbpI1POLEMkH/3TKrH5uCapUy+jM2V7+JP43 > Fn8EEJIgkuGHd+t1Jp2BI190Yyl+hO1hlarQJzDulGWBdYMtsxIGJ32Za9rJrSyo > C+nzfDpC5cKrLXXlk4vFq+GphnKOoOffQ7FCqQvElL89GBXxt7cvPCjk6X04BuYI > MhQYidxOozerdvNkH1iw9uC61zVhz0ahPqwuMbyzCg71BjLYo8NR+qYpqtiTMHjx > nXar6vcjzsrEQzi5Ul5hWjrgzQQgecFOeeZ5bQjTzhKfHMpUk1beI5rQuYxpuvVd > 8kA1YiOU5mfQqoqA+ZKpoG598Isp1vnTc+DQznJC9GbE4mgUWNO5n4J51U2OR5U= > =ypYB > -----END PGP SIGNATURE----- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From montuori@REDACTED Wed May 18 18:06:05 2011 From: montuori@REDACTED (kevin montuori) Date: Wed, 18 May 2011 12:06:05 -0400 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: Message-ID: On Wed, May 18, 2011 at 11:46 AM, Michael Turner wrote: > Why is this less readable to you? Because I can't use M-x show-matching-lines to find the heads. k. -- kevin montuori From michael.eugene.turner@REDACTED Wed May 18 18:08:06 2011 From: michael.eugene.turner@REDACTED (Michael Turner) Date: Thu, 19 May 2011 01:08:06 +0900 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: Message-ID: "Sorry, but Erlang doesn't *need* a better chance of survival." Now, wait, I'm really pretty sure that, less than a year ago, I saw both Peyton-Jones and Armstong in a video, speculating about the future of their respective favorite languages, and openly wondering what the long-term future held. In the meantime, I haven't noticed a dramatic increase in the frequency of Erlang job postings, though perhaps it's gone up. However, a doubling would still leave the number small. "Changing core language features that are solid,..." Except that that what I proposes fixes a weak spot (among other things): failed syntactic consistency. "... well thought out ..." Except that Joe Armstrong has just admitted (on this thread, IIRC) that the reason for the inconsistency is that they just didn't think about it at the time...." "... and non-harmful ..." Implying that what I suggest here IS harmful? I've asked what would break in existing code if this change were made. Nobody has answered me yet. Certainly not you. "... people /will/ follow it, almost to a religious end." "Religious"? Speak for yourself. Worship of technology leads to more problems than it's worth. "The issue you are attempting to get at is (again) an educational and experience one ..." Actually not. No amount of education and experience will make repeating the function name with every clause a DRY issue, for those who find that repetition as more of an obstacle than otherwise. No amount of education and experience will keep people from wondering, "Why this strange inconsistency?" And better documentation and training will only make more people ask that question. I didn't ask that question until I *stumbled* on the extended syntax for funs; I didn't know about it before. The current documentation makes it hard to find. -michael turner On Thu, May 19, 2011 at 12:29 AM, Parnell Springmeyer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Sorry, but Erlang doesn't *need* a better chance of survival. This > language is not just growing, it's booming. Changing core language > features that are solid, well thought out, and non-harmful (in other > words, they are, FEATURES) to make it more "adoptable" is a lot like > someone saying, "you have to quit that quirky smile so other people will > like you more." > > Sometimes, yes, there are features in a language that could use > refinement - but many times, in a mature language, the ratio between > need and usefulness in refining a feature further, drops significantly. > > Instead of changing something that is solid, educate the people that > have a hard time grasping it, build killer example applications that > exhibit the quirky style and idioms to a T - people /will/ follow it, > almost to a religious end. > > That's actually what I like about Erlang the most, the documentation has > so many gems in it like the efficiency guide (where many common idioms > are expressed with clear DO and DON'T DO examples) and style guide. > > RE: syntactic consistency: Erlang's syntax *IS* consistent - it's more > consistent than many languages I've touched. > > Is Erlang easy for a Perl programmer? I bet not, and Perl's syntax is > less consistent than Erlang's is in my opinion. The issue you are > attempting to get at is (again) an educational and experience one, not > something that is inherently wrong with the language or its expression > itself. > > I'm actually baffled by the efforts people are putting into different > Erlang VM frontends that look like Ruby or Python. Good on them for > exercising the freedom of open source but /why/? Erlang's syntax is > almost beautiful to me now after using it, it's so well suited for what > Erlang is good at! > > Erlang isn't that great for general purpose programming - you use > Python, Ruby, C, D, etc... for stuff like that. Erlang is great at fault > tolerance, easy parallelism (which isn't easy!), and hot code > loading. Features that are so difficult to do in the traditional > imperative environment that (to date) I have not seen a single > implementation of any one of those features that even approaches the > completeness of Erlang's. > > Michael Turner writes: > > > Another objection raised against this syntax change is that all > > functional languages violate DRY in this manner, so it's OK if Erlang > > does it too. This is a Principle of Least Surprise argument, and not > > bad as far as it goes. But how far does it go? > > > > Erlang will have a better chance of greater success and survival if you > > consider your recruitment base to be the overwhelming majority of > > programmers. And from what I can tell, > > > > http://www.langpop.com > > > > the overwhelming majority of programmers have no experience to speak > > of, when it comes to functional programming languages. Appealing to the > > "cross-training" benefit of coming from other FP languages seems like a > > pretty weak argument. Especially since all I'm asking for here is > > syntactic consistency *within* Erlang -- a PLoS argument in itself. > > > > Richard O'Keefe suggests that the syntactic consistency goal is better > > met by allowing a kind of limited-scope special-case fun name, > > permitting, e.g. > > > > Fact = fun F(0) -> 1; F(N) -> N*F(N-1) end. > > > > I could get behind that too, but I don't follow his reasoning from > > syntactic consistency, which is apparently that an unnamed fun has a > > name, it's just the degenerate case of a name. It's really there. We > > just can't see it. Hm, really? If that were true in Erlang as it > > stands, shouldn't I be able to write it this way? > > > > Fact = fun (0) -> 1; (N) -> N*''(N-1) end. > > > > Looks like it's not quite that simple. It compiles, but it doesn't know > > what module to look in for '', when it comes time to execute. In the > > shell, I get an error indicating that it tried to resolve ''/1 as a > > shell command. Even if I put it in a .erl file and compile it, there's > > no obvious way to tell the compiler what module to look in. ?MODULE:'' > > doesn't work. Nor does '':'', which I tried just for the hell of it. > > > > What Richard's suggesting appears to require a rigorous re-think of how > > scopes are defined in Erlang. What I'm suggesting amounts to simply > > asking the compiler to do some of your tedious keying for you. > > > > -michael turner > > > > > > On Wed, May 18, 2011 at 6:16 PM, Michael Turner < > > michael.eugene.turner@REDACTED> wrote: > > > > I can say > > > > fun (1)->2; > > (2)->1 > > end > > > > but, oddly, I can't define a named function in the analogous way, > > e.g.: > > > > factorial > > (1) -> 1; > > (N) -> N*factorial(N-1). > > > > gives me a syntax error. I find the latter more readable than > > > > factorial(1) -> 1; > > factorial(2) -> N*fact(N-1). > > > > It's also less to type and to read, which is consistent with the > > DRY principle ("Don't Repeat Yourself"). And it lends itself to > > reading a function definition as a set of cases. I think for Erlang > > newbies, it should therefore would be preferred: it helps > > underscore the pattern-matching style of Erlang function > > invocation. > > > > It also looks a *little* bit more like the mathematical convention > > for defining these sorts of functions, where you have "f(x) = ", > > centered vertically to the left of a big left "{" that (left-) > > encloses the list of expression/parameter-condition pairs in a > > two-column format, e.g., > > > > http://cnx.org/content/m29517/latest/Picture%2047.png > > > > So there's a (weak) argument from the Principle of Least Surprise > > here as well. > > > > It seems to me that, if anything, this requires only a > > *simplification* of the Erlang parser. That leaves only one obvious > > objection: would any existing code break if Erlang syntax were > > altered to allow this? > > > > -michael turner > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > - -- > Parnell "ixmatus" Springmeyer (http://ixmat.us) > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > > iQEcBAEBAgAGBQJN0+XsAAoJEPvtlbpI1POLEXEIAJrjAGVTkveBi5/akYNMjBEX > 8wI9twatnXh8sfg2ohGKr3P1hj4jTr9ARrG5wiB9OCArRkBymnjFeY5g2dkBDOhN > aN722l+yDPpUewAM58m0dDoDHjrHXvxF1MJejQJGhQ+Nr9fM+7G+4QIrCN9RvX1S > QTAS+OqOnl8lsS98yvUiXXLB5ehdHcR46Ix6Sq7UwSvqaOKZMoPrzkTtW3VyS5kf > i/uGbPZ1I3KQJYRShk2QlLis/tpXGtLDnYc1E5uADqeClDXy5Au6LWpNqUjNIiWw > h8I2emcBq5Ur7nivNUYgnVMjg+0qTkQOtttPpOJ25xIYv07L+eMfXneb5nRx4hc= > =GGPU > -----END PGP SIGNATURE----- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ixmatus@REDACTED Wed May 18 18:11:12 2011 From: ixmatus@REDACTED (Parnell Springmeyer) Date: Wed, 18 May 2011 09:11:12 -0700 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: (Michael Turner's message of "Thu, 19 May 2011 00:46:49 +0900") References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > If I argued only from syntactic consistency, you'd have a point. > Frankly, I don't really care about syntactic consistency, if it doesn't > get me something. Having to type less gets me something. Having more > readable code gets me something. Those are practical considerations, > not mere pedantic ones. Dude. How do you type more? When I type a ";" in my editor it auto-completes the function clause for me, that is an empty argument for changing something so trivial. Practical considerations would be better defined through education for core language features. > What you have as > > ? ?some_func(X, Y) -> > ? ? ? ?%% Long bit of code > ? ? ? ?...; > ? ?some_func(X, []) -> > ? ? ? ?%% More code > > could, as I proposed above, also be written > > ? some_func > ? ? ?(X,Y) -> %% long bit of code > ? ? ? ? ? ? ? ? ?...; > ? ? ?(X,[]) -> %% More code > ? ? ? ? ? ? ? ? ?.... Because, now I would have: some_func (X, Y) -> %% Long bit of code ...; (X, []) -> %% More code .... It makes the "structure" less flat when you start adding in indentation levels (which you *have* to do if you are writing non-trivial functions in order to be able to read them two weeks later). Again, the style you are suggesting is really well suited for functions with small and concise function bodies. Which, is well suited for the lambda. I use this all the time for small functions: SomeFun = fun (X, Y) -> %% Short peice of code; (X, []) -> %% Short peice of code. It's obviously much easier and quicker to read - but I don't beleive that is the case with named functions. > Why is this less readable to you? You could answer, "Because it's not > what I'm used to seeing in Erlang programs," but that begs the > question. If people were more used to seeing the latter -- because > making Erlang syntactically more self-consistent made it possible -- > that argument wouldn't have much force -- except as an argument from > pure conservatism. Then we would have someone like you complaining the opposite and proposing we all do it the way it is now - that person would probably be me. > And this is entirely apart from "long bit of code" being a classic > Smell anyway: > > ??http://www.soberit.hut.fi/mmantyla/BadCodeSmellsTaxonomy.htm This is why I used the word "pedantic", don't I know abstraction and orthogonality is preferred over monolithic functions? Of course I do. But, what does one consider "long"? Some functions I write are /better/ written as a long function to avoid unnecessary (read: pedantic) abstraction that actually clouds the intent. - -- Parnell "ixmatus" Springmeyer (http://ixmat.us) -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJN0++gAAoJEPvtlbpI1POLn14H/2yY/dpNJVrMOnSPVrxjFRBY peMjGJZM/tRmReMWM9b6Df+hoRMXmPqZ+253LaAKYTfuehlowwXvG/HBRiFNB+vv +rOIcP/OOqeJNJp3MtRIKxKvqiubQMKfbalxh4Au0xzCp70o6fKYKQKZY1hS6TiY jtkeKxXU4vnmGockYhAlUlHNJLmopbVZGk97XZ2NtAqFDI8UmaWCZfSK7zN7Ebnm HLIXrv13TrwHy/i9xonuGrOvV8W7QPtzspGQxcix3a6JMEFox2E06tBRBHcVK1I8 tAB6i9RVblWUqi4i4a1jjan9rk/p366sPz3yBUQVnPmgdezaA/q+mxsGxBAp6pE= =YwFM -----END PGP SIGNATURE----- From michael.eugene.turner@REDACTED Wed May 18 18:13:11 2011 From: michael.eugene.turner@REDACTED (Michael Turner) Date: Thu, 19 May 2011 01:13:11 +0900 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: Message-ID: "Because I can't use M-x show-matching-lines to find the heads." That would be "less browsable", rather than "less readable". That's a reasonable objection, and in fact the only truly concrete objection I've seen. (If I may lump it together with "it breaks ctags", mentioned early, which is undoubtedly also true.) But programming tools are not carved in stone either. If, for example, somebody had to hack ctags to generate the right search strings for this function format, it's not the end of the world. It's just a matter of somebody wading into ctags and enduring the pain of it for a few days. Finally, nobody would be making you do this to your own code, and where you had to deal with it in others, relatively trivial refactoring tools would make it possible to "toggle" code back and forth between the two allowed forms. -michael turner On Thu, May 19, 2011 at 1:06 AM, kevin montuori wrote: > On Wed, May 18, 2011 at 11:46 AM, Michael Turner > wrote: > > > Why is this less readable to you? > > Because I can't use M-x show-matching-lines to find the heads. > > > k. > > -- > kevin montuori > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rtrlists@REDACTED Wed May 18 18:13:54 2011 From: rtrlists@REDACTED (Robert Raschke) Date: Wed, 18 May 2011 17:13:54 +0100 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: Message-ID: Just 'cause it's this kind of a thread ;-) "it would be frightening to estimate how much time programmers have wasted formatting their text so comments line up and other such idiocies. proportional fronts are liberating because you get back all that time. if your program needs to be laid out with vertical alignment to be understood, rewrite it." Rob Pike -------------- next part -------------- An HTML attachment was scrubbed... URL: From careers@REDACTED Wed May 18 18:12:19 2011 From: careers@REDACTED (careers@REDACTED) Date: Wed, 18 May 2011 10:12:19 -0600 Subject: [erlang-questions] [Hiring] Senior Erlang Programmer Message-ID: <815eb301447cd8e334ebe60af84a9fff.squirrel@mail.cabonetworks.com> Resumes by email to careers@REDACTED Description: This is a full-time, on-site position. Telecommuting is not an option. Candidates must be authorized to work in the USA and be willing to relocate if necessary. Based out of Delray Beach, FL, we are searching for a Senior Erlang Programmer to join our skilled team. Candidate must be equipped to take full ownership of independent tasks and work with minimal supervision in an agile environment. Candidate will assist in building highly scalable data intelligence systems, network services and integrating with 3rd party systems. Candidate will work with interface developers to build out secure web based application interfaces and underlying servers. Demonstrable experience in Erlang/OTP is required, but candidates with Haskell experience will be considered. Candidate should be familiar with NoSQL storage engines such as CouchDB, MongoDB, Cassandra. Responsibilities: Developing fault-tolerant, distributed messaging systems with extreme performance and reliability requirements Developing systems and algorithms for real-time data analysis in a high throughput environment Working alongside interface developers to produce scalable Web application interfaces Collaborate with product managers, designers, architects, and researchers to refine the user experience Integrate with third party software and systems Maintain full coverage unit tests and documentation for all code produced Updating and re-factoring of existing code base Work in an Agile Development Environment with limited Specification documents Requirements: US Work Eligibility 4 years professional experience MINIMUM Must be able to work out of our Delray Beach offices Experience developing for/on Linux, BSD or Solaris platforms. Highly proficient in Erlang/OTP and at least one of the following: C, C++, Java, Python Experience in fault-tolerant distributed/networked systems development Experience with network server programming Demonstrable experience with 'NoSQL' storage engine(s) (Document or Key-Value based) Ability to accurately and thoroughly document your work Knowledge of Test-driven and Agile development methodologies Experience with Mercurial or similar version control system(s) Enthusiasm for solving challenging and interesting problems Excellent communication skills The following skills would be beneficial: Experience with Business Intelligence and Report Generation platforms Demonstrable skills with PHP, JavaScript, CSS, XHTML Enterprise Messaging platforms experience (EG ActiveMQ, OpenMQ) Active participation and deployment of code in the Open Source community a plus Experience in Online Marketing space (Display/Mail/SEO) CRM/ERP/CMS experience MTA integration experience Salary/Benefits: Salary commensurate with experience Paid vacation days, public holidays and sick days included Casual Working Environment From dang@REDACTED Wed May 18 18:17:43 2011 From: dang@REDACTED (Daniel Goertzen) Date: Wed, 18 May 2011 11:17:43 -0500 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: Message-ID: On Wed, May 18, 2011 at 11:08 AM, Michael Turner < michael.eugene.turner@REDACTED> wrote "I didn't ask that question until I *stumbled* on the extended syntax for funs; I didn't know about it before. The current documentation makes it hard to find." I think this is a key issue here: multi-clause funs just don't happen all that often. It was very late in my Erlang learning experience that I found the need for multi-clause funs, and I easily found the documentation at the time. I did notice the syntax inconsistency, but didn't care. Anyway, it is often a good idea to break funs out into full functions to reduce nesting and facilitate tracing. Lots of funs make programs hard to debug. Dan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.eugene.turner@REDACTED Wed May 18 18:19:25 2011 From: michael.eugene.turner@REDACTED (Michael Turner) Date: Thu, 19 May 2011 01:19:25 +0900 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: Message-ID: "When I type a ";" in my editor it auto-completes the function clause for me, ..." I apologize for being one of those cavemen who still uses vi. And for thinking, "If a program can autocomplete anything more than an identifier in context, it must be generating a pretty redundant piece of code to begin with." -michael turner On Thu, May 19, 2011 at 1:11 AM, Parnell Springmeyer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > If I argued only from syntactic consistency, you'd have a point. > > Frankly, I don't really care about syntactic consistency, if it doesn't > > get me something. Having to type less gets me something. Having more > > readable code gets me something. Those are practical considerations, > > not mere pedantic ones. Dude. > > How do you type more? When I type a ";" in my editor it auto-completes > the function clause for me, that is an empty argument for changing > something so trivial. > > Practical considerations would be better defined through education for > core language features. > > > What you have as > > > > some_func(X, Y) -> > > %% Long bit of code > > ...; > > some_func(X, []) -> > > %% More code > > > > could, as I proposed above, also be written > > > > some_func > > (X,Y) -> %% long bit of code > > ...; > > (X,[]) -> %% More code > > .... > > Because, now I would have: > > some_func > (X, Y) -> > %% Long bit of code > ...; > (X, []) -> > %% More code > .... > > It makes the "structure" less flat when you start adding in indentation > levels (which you *have* to do if you are writing non-trivial functions > in order to be able to read them two weeks later). > > Again, the style you are suggesting is really well suited for functions > with small and concise function bodies. Which, is well suited for the > lambda. I use this all the time for small functions: > > SomeFun = fun (X, Y) -> %% Short peice of code; > (X, []) -> %% Short peice of code. > > It's obviously much easier and quicker to read - but I don't beleive > that is the case with named functions. > > > Why is this less readable to you? You could answer, "Because it's not > > what I'm used to seeing in Erlang programs," but that begs the > > question. If people were more used to seeing the latter -- because > > making Erlang syntactically more self-consistent made it possible -- > > that argument wouldn't have much force -- except as an argument from > > pure conservatism. > > Then we would have someone like you complaining the opposite and > proposing we all do it the way it is now - that person would probably be > me. > > > And this is entirely apart from "long bit of code" being a classic > > Smell anyway: > > > > http://www.soberit.hut.fi/mmantyla/BadCodeSmellsTaxonomy.htm > > This is why I used the word "pedantic", don't I know abstraction and > orthogonality is preferred over monolithic functions? Of course I > do. But, what does one consider "long"? Some functions I write are > /better/ written as a long function to avoid unnecessary (read: > pedantic) abstraction that actually clouds the intent. > > - -- > Parnell "ixmatus" Springmeyer (http://ixmat.us) > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > > iQEcBAEBAgAGBQJN0++gAAoJEPvtlbpI1POLn14H/2yY/dpNJVrMOnSPVrxjFRBY > peMjGJZM/tRmReMWM9b6Df+hoRMXmPqZ+253LaAKYTfuehlowwXvG/HBRiFNB+vv > +rOIcP/OOqeJNJp3MtRIKxKvqiubQMKfbalxh4Au0xzCp70o6fKYKQKZY1hS6TiY > jtkeKxXU4vnmGockYhAlUlHNJLmopbVZGk97XZ2NtAqFDI8UmaWCZfSK7zN7Ebnm > HLIXrv13TrwHy/i9xonuGrOvV8W7QPtzspGQxcix3a6JMEFox2E06tBRBHcVK1I8 > tAB6i9RVblWUqi4i4a1jjan9rk/p366sPz3yBUQVnPmgdezaA/q+mxsGxBAp6pE= > =YwFM > -----END PGP SIGNATURE----- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.eugene.turner@REDACTED Wed May 18 18:21:12 2011 From: michael.eugene.turner@REDACTED (Michael Turner) Date: Thu, 19 May 2011 01:21:12 +0900 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: Message-ID: "Anyway, it is often a good idea to break funs out into full functions to reduce nesting and facilitate tracing. Lots of funs make programs hard to debug." I agree. On both points. But neither point is really relevant to my case here. I'm not proposing that people write more funs. I'm proposing that writing named functions enjoy one of the syntactic benefits of funs. -michael turner On Thu, May 19, 2011 at 1:17 AM, Daniel Goertzen < dang@REDACTED> wrote: > > > On Wed, May 18, 2011 at 11:08 AM, Michael Turner < > michael.eugene.turner@REDACTED> wrote > > "I didn't ask that question until I *stumbled* on the extended syntax for > funs; I didn't know about it before. The current documentation makes it hard > to find." > > > > > I think this is a key issue here: multi-clause funs just don't happen all > that often. It was very late in my Erlang learning experience that I found > the need for multi-clause funs, and I easily found the documentation at the > time. I did notice the syntax inconsistency, but didn't care. Anyway, it > is often a good idea to break funs out into full functions to reduce nesting > and facilitate tracing. Lots of funs make programs hard to debug. > > Dan. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.eugene.turner@REDACTED Wed May 18 18:26:01 2011 From: michael.eugene.turner@REDACTED (Michael Turner) Date: Thu, 19 May 2011 01:26:01 +0900 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: Message-ID: "Then we would have someone like you complaining the opposite and proposing we all do it the way it is now..." Another strawman. Where do I advocate using multi-clause fun syntax for named functions *exclusively*? I don't. Clearly, even if the proposal here were wildly popular, there would be the problem of compatibility with existing code. "Practical considerations would be better defined through education for core language features." Where have I suggested changing even ONE single core language feature? Strawmen, strawmen, strawmen. -michael turner On Thu, May 19, 2011 at 1:11 AM, Parnell Springmeyer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > If I argued only from syntactic consistency, you'd have a point. > > Frankly, I don't really care about syntactic consistency, if it doesn't > > get me something. Having to type less gets me something. Having more > > readable code gets me something. Those are practical considerations, > > not mere pedantic ones. Dude. > > How do you type more? When I type a ";" in my editor it auto-completes > the function clause for me, that is an empty argument for changing > something so trivial. > > Practical considerations would be better defined through education for > core language features. > > > What you have as > > > > some_func(X, Y) -> > > %% Long bit of code > > ...; > > some_func(X, []) -> > > %% More code > > > > could, as I proposed above, also be written > > > > some_func > > (X,Y) -> %% long bit of code > > ...; > > (X,[]) -> %% More code > > .... > > Because, now I would have: > > some_func > (X, Y) -> > %% Long bit of code > ...; > (X, []) -> > %% More code > .... > > It makes the "structure" less flat when you start adding in indentation > levels (which you *have* to do if you are writing non-trivial functions > in order to be able to read them two weeks later). > > Again, the style you are suggesting is really well suited for functions > with small and concise function bodies. Which, is well suited for the > lambda. I use this all the time for small functions: > > SomeFun = fun (X, Y) -> %% Short peice of code; > (X, []) -> %% Short peice of code. > > It's obviously much easier and quicker to read - but I don't beleive > that is the case with named functions. > > > Why is this less readable to you? You could answer, "Because it's not > > what I'm used to seeing in Erlang programs," but that begs the > > question. If people were more used to seeing the latter -- because > > making Erlang syntactically more self-consistent made it possible -- > > that argument wouldn't have much force -- except as an argument from > > pure conservatism. > > Then we would have someone like you complaining the opposite and > proposing we all do it the way it is now - that person would probably be > me. > > > And this is entirely apart from "long bit of code" being a classic > > Smell anyway: > > > > http://www.soberit.hut.fi/mmantyla/BadCodeSmellsTaxonomy.htm > > This is why I used the word "pedantic", don't I know abstraction and > orthogonality is preferred over monolithic functions? Of course I > do. But, what does one consider "long"? Some functions I write are > /better/ written as a long function to avoid unnecessary (read: > pedantic) abstraction that actually clouds the intent. > > - -- > Parnell "ixmatus" Springmeyer (http://ixmat.us) > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > > iQEcBAEBAgAGBQJN0++gAAoJEPvtlbpI1POLn14H/2yY/dpNJVrMOnSPVrxjFRBY > peMjGJZM/tRmReMWM9b6Df+hoRMXmPqZ+253LaAKYTfuehlowwXvG/HBRiFNB+vv > +rOIcP/OOqeJNJp3MtRIKxKvqiubQMKfbalxh4Au0xzCp70o6fKYKQKZY1hS6TiY > jtkeKxXU4vnmGockYhAlUlHNJLmopbVZGk97XZ2NtAqFDI8UmaWCZfSK7zN7Ebnm > HLIXrv13TrwHy/i9xonuGrOvV8W7QPtzspGQxcix3a6JMEFox2E06tBRBHcVK1I8 > tAB6i9RVblWUqi4i4a1jjan9rk/p366sPz3yBUQVnPmgdezaA/q+mxsGxBAp6pE= > =YwFM > -----END PGP SIGNATURE----- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ixmatus@REDACTED Wed May 18 18:36:16 2011 From: ixmatus@REDACTED (Parnell Springmeyer) Date: Wed, 18 May 2011 09:36:16 -0700 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: (Michael Turner's message of "Thu, 19 May 2011 01:26:01 +0900") References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alright dude, you seriously need to chill out - I know the "someone's wrong on the internet" fever is hard to quench but at this point you're nit picking and laying flame bait. Which I won't bite because I've already wasted a good portion of my day on this exchange. We're ultimately on the same side - I love the language as it is, period. If you think something should be changed, go do it, other people are writing different front-ends to the VM so I imagine it would be a trivial change for you to make this particular change yourself. If it catches on, I'm sure the maintainers would be happy to merge with backwards compatibility for those (like me) that prefer the verbose syntax. Have a nice day and please stop taking these emails personally - it truly is "whatevs". :) Michael Turner writes: > "Then we would have someone like you complaining the opposite > and?proposing we all do it the way it is now..." > > Another strawman. Where do I advocate using multi-clause fun syntax for > named functions *exclusively*? I don't. Clearly, even if the proposal > here were wildly popular, there would be the problem of compatibility > with existing code. > > "Practical considerations would be better defined through education > for?core language features." > > Where have I suggested changing even ONE single core language feature? > > Strawmen, strawmen, strawmen. > > -michael turner > > On Thu, May 19, 2011 at 1:11 AM, Parnell Springmeyer > wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > If I argued only from syntactic consistency, you'd have a point. > > Frankly, I don't really care about syntactic consistency, if it > doesn't > > get me something. Having to type less gets me something. Having > more > > readable code gets me something. Those are practical > considerations, > > not mere pedantic ones. Dude. > > How do you type more? When I type a ";" in my editor it > auto-completes > the function clause for me, that is an empty argument for changing > something so trivial. > > Practical considerations would be better defined through education > for > core language features. > > > What you have as > > > > ? ?some_func(X, Y) -> > > ? ? ? ?%% Long bit of code > > ? ? ? ?...; > > ? ?some_func(X, []) -> > > ? ? ? ?%% More code > > > > could, as I proposed above, also be written > > > > ? some_func > > ? ? ?(X,Y) -> %% long bit of code > > ? ? ? ? ? ? ? ? ?...; > > ? ? ?(X,[]) -> %% More code > > ? ? ? ? ? ? ? ? ?.... > > Because, now I would have: > > ? ?some_func > ? ? ? ?(X, Y) -> > ? ? ? ? ? ?%% Long bit of code > ? ? ? ? ? ?...; > ? ? ? ?(X, []) -> > ? ? ? ? ? ?%% More code > ? ? ? ? ? ?.... > > It makes the "structure" less flat when you start adding in > indentation > levels (which you *have* to do if you are writing non-trivial > functions > in order to be able to read them two weeks later). > > Again, the style you are suggesting is really well suited for > functions > with small and concise function bodies. Which, is well suited for > the > lambda. I use this all the time for small functions: > > ? ?SomeFun = fun (X, Y) ?-> %% Short peice of code; > ? ? ? ? ? ? ? ? ?(X, []) -> %% Short peice of code. > > It's obviously much easier and quicker to read - but I don't > beleive > that is the case with named functions. > > > Why is this less readable to you? You could answer, "Because it's > not > > what I'm used to seeing in Erlang programs," but that begs the > > question. If people were more used to seeing the latter -- > because > > making Erlang syntactically more self-consistent made it possible > -- > > that argument wouldn't have much force -- except as an argument > from > > pure conservatism. > > Then we would have someone like you complaining the opposite and > proposing we all do it the way it is now - that person would > probably be > me. > > > And this is entirely apart from "long bit of code" being a > classic > > Smell anyway: > > > > ??http://www.soberit.hut.fi/mmantyla/BadCodeSmellsTaxonomy.htm > > This is why I used the word "pedantic", don't I know abstraction > and > orthogonality is preferred over monolithic functions? Of course I > do. But, what does one consider "long"? Some functions I write are > /better/ written as a long function to avoid unnecessary (read: > pedantic) abstraction that actually clouds the intent. > > - -- > Parnell "ixmatus" Springmeyer (http://ixmat.us) > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > > iQEcBAEBAgAGBQJN0++gAAoJEPvtlbpI1POLn14H/2yY/dpNJVrMOnSPVrxjFRBY > peMjGJZM/tRmReMWM9b6Df+hoRMXmPqZ+253LaAKYTfuehlowwXvG/HBRiFNB+vv > +rOIcP/OOqeJNJp3MtRIKxKvqiubQMKfbalxh4Au0xzCp70o6fKYKQKZY1hS6TiY > jtkeKxXU4vnmGockYhAlUlHNJLmopbVZGk97XZ2NtAqFDI8UmaWCZfSK7zN7Ebnm > HLIXrv13TrwHy/i9xonuGrOvV8W7QPtzspGQxcix3a6JMEFox2E06tBRBHcVK1I8 > tAB6i9RVblWUqi4i4a1jjan9rk/p366sPz3yBUQVnPmgdezaA/q+mxsGxBAp6pE= > =YwFM > -----END PGP SIGNATURE----- > - -- Parnell "ixmatus" Springmeyer (http://ixmat.us) -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJN0/WAAAoJEPvtlbpI1POLi7sIALtXMnbdt7pFvHGSUYsjGCzP 4yYfxdEcCgzcTlobee4I4WUhgtHFrk12tgA0zEG3s/hkFnY2up9h9PKnDxvAcD0U h8ccxyNg6WRvhTfUq/82hyEYoo5NsOe/Y+4cmKSyhJILY/N8w2CqIJbSaQbnQ6rS ELN5Xde5QS1mZU+H0fGxLZOEu6BIWL5pPXd27S/l+NON3wi/4Jl47S8AM/4kPX5Z TKZzDxvNYZSk49G1g3QG5W2iNK7kL1lrxNFfUduhd80znDbbeHtyklxF69HJiPec KgT+NloCufp/dImeTkl6taW9FhILZ/VgGGDYOSs0hx1kArHn1Xlc4XmPccvgAbA= =0Xu4 -----END PGP SIGNATURE----- From mihai@REDACTED Wed May 18 18:40:16 2011 From: mihai@REDACTED (Mihai Balea) Date: Wed, 18 May 2011 12:40:16 -0400 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: Message-ID: <1930B4D4-54DD-4F80-ACDE-BBE983315E64@hates.ms> On May 18, 2011, at 12:13 PM, Michael Turner wrote: > "Because I can't use M-x show-matching-lines to find the heads." > > That would be "less browsable", rather than "less readable". That's a reasonable objection, and in fact the only truly concrete objection I've seen. (If I may lump it together with "it breaks ctags", mentioned early, which is undoubtedly also true.) Here's another argument: after I spend 8 hours looking at code, I find that having the function name attached to each clause makes it easier to recognize where clauses begin and end. I wouldn't worry about typing a few extra characters. I find that I spend an order or magnitude more time reading code and thinking about it than typing it out. Maybe you are different and you are actually constrained by typing speed, but I doubt it. I care about readability and having function names in each clause makes things more readable for me. > Finally, nobody would be making you do this to your own code, and where you had to deal with it in others, relatively trivial refactoring tools would make it possible to "toggle" code back and forth between the two allowed forms. So basically you'd take a small source of inconsistency (because multiple clause funs aren't that common in the wild) and turn it into a huge one. Isn't it bad enough that people are allowed to choose their own indentation style? (I kid, I kid... /ducks) Mihai From michael.eugene.turner@REDACTED Wed May 18 18:50:33 2011 From: michael.eugene.turner@REDACTED (Michael Turner) Date: Thu, 19 May 2011 01:50:33 +0900 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: <1930B4D4-54DD-4F80-ACDE-BBE983315E64@hates.ms> References: <1930B4D4-54DD-4F80-ACDE-BBE983315E64@hates.ms> Message-ID: I wish I could be nice here, but ... under provocation from another critic, forgive me for summing this up as just another strawman argument. In particular, claiming what I propose is all about writeability, when I've actually already made an argument from readability (in the eye of the beholder, perhaps). Furthermore claiming that what I propose will increase "inconsistency", when at worst what it would increase would be stylistic variation -- about which people argue pointlessly anyway, so where's the loss? There have a been two sensible counter-arguments here, both of them in the class "the existing tools wouldn't know about this move toward syntactic consistency." My answer to both is the same: yes, good point, but -- tools aren't carved in stone either. I'm still waiting for the answer to the real showstopper question: would any existing code break, under my proposal? -michael turner On Thu, May 19, 2011 at 1:40 AM, Mihai Balea wrote: > On May 18, 2011, at 12:13 PM, Michael Turner wrote: > > > "Because I can't use M-x show-matching-lines to find the heads." > > > > That would be "less browsable", rather than "less readable". That's a > reasonable objection, and in fact the only truly concrete objection I've > seen. (If I may lump it together with "it breaks ctags", mentioned early, > which is undoubtedly also true.) > > Here's another argument: after I spend 8 hours looking at code, I find that > having the function name attached to each clause makes it easier to > recognize where clauses begin and end. I wouldn't worry about typing a few > extra characters. I find that I spend an order or magnitude more time > reading code and thinking about it than typing it out. Maybe you are > different and you are actually constrained by typing speed, but I doubt it. > I care about readability and having function names in each clause makes > things more readable for me. > > > Finally, nobody would be making you do this to your own code, and where > you had to deal with it in others, relatively trivial refactoring tools > would make it possible to "toggle" code back and forth between the two > allowed forms. > > > So basically you'd take a small source of inconsistency (because multiple > clause funs aren't that common in the wild) and turn it into a huge one. > > Isn't it bad enough that people are allowed to choose their own indentation > style? (I kid, I kid... /ducks) > > Mihai -------------- next part -------------- An HTML attachment was scrubbed... URL: From jack@REDACTED Wed May 18 19:03:16 2011 From: jack@REDACTED (Jack Moffitt) Date: Wed, 18 May 2011 11:03:16 -0600 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: <1930B4D4-54DD-4F80-ACDE-BBE983315E64@hates.ms> Message-ID: > I'm still waiting for the answer to the real showstopper question: would any > existing code break, under my proposal? Assuming the answer is no, then I think it's fine to fix the inconsistency an add this alternate notation. It would be nice to fix it the other way to so that you could use the normal syntax in funs, but I'm guessing that is a lot harder than just a parser change. I could see using it for short functions. I'll also point out that this is name-less clause syntax is the same as in Clojure: (defn mymax ([x] x) ([x y] (if (> x y) x y)) ([x y & more] (reduce mymax (mymax x y) more))) jack. From michael.eugene.turner@REDACTED Wed May 18 19:50:41 2011 From: michael.eugene.turner@REDACTED (Michael Turner) Date: Thu, 19 May 2011 02:50:41 +0900 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: <1930B4D4-54DD-4F80-ACDE-BBE983315E64@hates.ms> Message-ID: By the way, I've been saying "my proposal" on this thread, but mainly because I missed where Justus (mapandfold@REDACTED) first brought it up, just days ago. I didn't read that thread because I assumed it was a newbie question about function declaration syntax. The problem is actually one that bothered me when I first learned Prolog over 30 years ago, but Justus seems to be the first one to bring it up. -michael turner -------------- next part -------------- An HTML attachment was scrubbed... URL: From freza@REDACTED Wed May 18 21:38:10 2011 From: freza@REDACTED (Jachym Holecek) Date: Wed, 18 May 2011 20:38:10 +0100 Subject: [erlang-questions] supervisor children's pid In-Reply-To: <20110518115713.GF7320@aluminum.local> References: <20110518044824.GC7320@aluminum.local> <20110518083422.GB1762@hanele.lan> <20110518115713.GF7320@aluminum.local> Message-ID: <20110518193810.GA737@hanele.lan> # Vance Shipley 2011-05-18: > On Wed, May 18, 2011 at 09:34:22AM +0100, Jachym Holecek wrote: > } Nice trick, but there is no guarantee process' siblings will already be > } started after some arbitrary timeout -- try this on a heavily loaded > } system... it's just not safe. > > You try it. I already have. Oops, sorry, good point (I mean your reply to Robert). BR, -- Jachym From spawn.think@REDACTED Wed May 18 22:03:10 2011 From: spawn.think@REDACTED (Ahmed Omar) Date: Wed, 18 May 2011 22:03:10 +0200 Subject: [erlang-questions] [EUG-NL] Erlang Users' Group Netherlands? Message-ID: Hi everyone, I was thinking to start a user group for Erlangers in Netherlands, and i was wondering how many are out there? -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think -------------- next part -------------- An HTML attachment was scrubbed... URL: From koops.j@REDACTED Wed May 18 22:33:20 2011 From: koops.j@REDACTED (Jeroen Koops) Date: Wed, 18 May 2011 22:33:20 +0200 Subject: [erlang-questions] [EUG-NL] Erlang Users' Group Netherlands? In-Reply-To: References: Message-ID: I would be interested. I'm in Amsterdam, by the way. On Wed, May 18, 2011 at 10:03 PM, Ahmed Omar wrote: > Hi everyone, > I was thinking to start a user group for Erlangers in Netherlands, and i > was wondering how many are out there? > > -- > Best Regards, > - Ahmed Omar > http://nl.linkedin.com/in/adiaa > Follow me on twitter > @spawn_think > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From spawn.think@REDACTED Wed May 18 22:45:15 2011 From: spawn.think@REDACTED (Ahmed Omar) Date: Wed, 18 May 2011 22:45:15 +0200 Subject: [erlang-questions] [EUG-NL] Erlang Users' Group Netherlands? In-Reply-To: References: Message-ID: Nice, and I'm in Rotterdam Anybody else? On Wed, May 18, 2011 at 10:33 PM, Jeroen Koops wrote: > I would be interested. I'm in Amsterdam, by the way. > > On Wed, May 18, 2011 at 10:03 PM, Ahmed Omar wrote: > >> Hi everyone, >> I was thinking to start a user group for Erlangers in Netherlands, and i >> was wondering how many are out there? >> >> -- >> Best Regards, >> - Ahmed Omar >> http://nl.linkedin.com/in/adiaa >> Follow me on twitter >> @spawn_think >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Wed May 18 23:40:40 2011 From: erlang@REDACTED (Joe Armstrong) Date: Wed, 18 May 2011 23:40:40 +0200 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: Message-ID: On Wed, May 18, 2011 at 5:11 PM, Parnell Springmeyer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > You're being pedantic dude. I'm sure Joe Armstrong and the other > programmers that designed and work on Erlang are acutely aware of DRY, > PoLS, and a whole bunch of others. > Absolutly - DRY is tricky though - it's sometimes quicker to repeat yourself than find the code to repeat. And sometimes when you repeat yourself you find you didn't - you thought you repeated yourself - bit on closer inspection you improved some old version. Since I actually repeat myself a lot I have another problem which of the 17 almost similar versions of X was the best ... One the subject of syntax there's another inconstancy that nobody seems to have noticed. All arguments in function calls *EXCEPT THE LAST* have commas after them. We write foo(a,b,c) but to make it easy to swap the arguments we should write foo(a,b,c,) - actually C, Java and virtually every language under the sun gets this wrong. Oh and English clauses are separated by commas, *EXCEPT THE LAST*. This, I think, would be a lot better,. Or so it is argued on the placement of ;'s in Erlang :-) Changing syntax is *incredibly difficult* project managers get apoplectic at the thought of retesting million lines of code - I know they *should* be able to retest overnight - but sometimes they have to book special purpose test facilities weeks in advance. For those who want to experiment with a new syntax there is an easy method - make a new file extension .erl1 hack the parser and write some code that transforms .erl1 files to .erl. If you want to think about language changes why don't we have a long debate over higher order modules - not syntax. Me, I'd like to say L = [{foo, fun(X,Y) -> ... end}, {bar, fun(X) -> ... end}] then have couple of new bifs Mod = list_to_mod(L) to compose a module from a load of funs and mod_to_list to do the inverse. /Joe > > Personally, I think it is a feature to state the function name when > defining another function clause. > > some_func(X, Y) -> > %% Long bit of code > ...; > some_func(X, []) -> > %% More code > .... > > Without it, scanning the source could get confusing. > > Michael Turner writes: > > > I can say > > > > fun (1)->2; > > (2)->1 > > end > > > > but, oddly, I can't define a named function in the analogous way, e.g.: > > > > factorial > > (1) -> 1; > > (N) -> N*factorial(N-1). > > > > gives me a syntax error. I find the latter more readable than > > > > factorial(1) -> 1; > > factorial(2) -> N*fact(N-1). > > > > It's also less to type and to read, which is consistent with the DRY > > principle ("Don't Repeat Yourself"). And it lends itself to reading a > > function definition as a set of cases. I think for Erlang newbies, it > > should therefore would be preferred: it helps underscore the > > pattern-matching style of Erlang function invocation. > > > > It also looks a *little* bit more like the mathematical convention for > > defining these sorts of functions, where you have "f(x) = ", centered > > vertically to the left of a big left "{" that (left-)encloses the list > > of expression/parameter-condition pairs in a two-column format, e.g., > > > > http://cnx.org/content/m29517/latest/Picture%2047.png > > > > So there's a (weak) argument from the Principle of Least Surprise here > > as well. > > > > It seems to me that, if anything, this requires only a *simplification* > > of the Erlang parser. That leaves only one obvious objection: would any > > existing code break if Erlang syntax were altered to allow this? > > > > -michael turner > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > - -- > Parnell "ixmatus" Springmeyer (http://ixmat.us) > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > > iQEcBAEBAgAGBQJN0+GfAAoJEPvtlbpI1POLEMkH/3TKrH5uCapUy+jM2V7+JP43 > Fn8EEJIgkuGHd+t1Jp2BI190Yyl+hO1hlarQJzDulGWBdYMtsxIGJ32Za9rJrSyo > C+nzfDpC5cKrLXXlk4vFq+GphnKOoOffQ7FCqQvElL89GBXxt7cvPCjk6X04BuYI > MhQYidxOozerdvNkH1iw9uC61zVhz0ahPqwuMbyzCg71BjLYo8NR+qYpqtiTMHjx > nXar6vcjzsrEQzi5Ul5hWjrgzQQgecFOeeZ5bQjTzhKfHMpUk1beI5rQuYxpuvVd > 8kA1YiOU5mfQqoqA+ZKpoG598Isp1vnTc+DQznJC9GbE4mgUWNO5n4J51U2OR5U= > =ypYB > -----END PGP SIGNATURE----- > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Wed May 18 23:47:45 2011 From: erlang@REDACTED (Joe Armstrong) Date: Wed, 18 May 2011 23:47:45 +0200 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: Message-ID: On Wed, May 18, 2011 at 5:29 PM, Parnell Springmeyer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Sorry, but Erlang doesn't *need* a better chance of survival. This > language is not just growing, it's booming. Changing core language > features that are solid, well thought out, and non-harmful (in other > words, they are, FEATURES) to make it more "adoptable" is a lot like > someone saying, "you have to quit that quirky smile so other people will > like you more." > Languages survive forever once they get to the point where 1) legacy applications in the language still earn money 2) it costs more to convert to a new language than maintain the existing app in the old language Erlang reached this point, many years ago. Right now Erlang companies have a commercial advantage over non-erlang companies and so there is not much point in trying to spread the language further - you just loose your commercial advantage. /Joe > > Sometimes, yes, there are features in a language that could use > refinement - but many times, in a mature language, the ratio between > need and usefulness in refining a feature further, drops significantly. > > Instead of changing something that is solid, educate the people that > have a hard time grasping it, build killer example applications that > exhibit the quirky style and idioms to a T - people /will/ follow it, > almost to a religious end. > > That's actually what I like about Erlang the most, the documentation has > so many gems in it like the efficiency guide (where many common idioms > are expressed with clear DO and DON'T DO examples) and style guide. > > RE: syntactic consistency: Erlang's syntax *IS* consistent - it's more > consistent than many languages I've touched. > > Is Erlang easy for a Perl programmer? I bet not, and Perl's syntax is > less consistent than Erlang's is in my opinion. The issue you are > attempting to get at is (again) an educational and experience one, not > something that is inherently wrong with the language or its expression > itself. > > I'm actually baffled by the efforts people are putting into different > Erlang VM frontends that look like Ruby or Python. Good on them for > exercising the freedom of open source but /why/? Erlang's syntax is > almost beautiful to me now after using it, it's so well suited for what > Erlang is good at! > > Erlang isn't that great for general purpose programming - you use > Python, Ruby, C, D, etc... for stuff like that. Erlang is great at fault > tolerance, easy parallelism (which isn't easy!), and hot code > loading. Features that are so difficult to do in the traditional > imperative environment that (to date) I have not seen a single > implementation of any one of those features that even approaches the > completeness of Erlang's. > > Michael Turner writes: > > > Another objection raised against this syntax change is that all > > functional languages violate DRY in this manner, so it's OK if Erlang > > does it too. This is a Principle of Least Surprise argument, and not > > bad as far as it goes. But how far does it go? > > > > Erlang will have a better chance of greater success and survival if you > > consider your recruitment base to be the overwhelming majority of > > programmers. And from what I can tell, > > > > http://www.langpop.com > > > > the overwhelming majority of programmers have no experience to speak > > of, when it comes to functional programming languages. Appealing to the > > "cross-training" benefit of coming from other FP languages seems like a > > pretty weak argument. Especially since all I'm asking for here is > > syntactic consistency *within* Erlang -- a PLoS argument in itself. > > > > Richard O'Keefe suggests that the syntactic consistency goal is better > > met by allowing a kind of limited-scope special-case fun name, > > permitting, e.g. > > > > Fact = fun F(0) -> 1; F(N) -> N*F(N-1) end. > > > > I could get behind that too, but I don't follow his reasoning from > > syntactic consistency, which is apparently that an unnamed fun has a > > name, it's just the degenerate case of a name. It's really there. We > > just can't see it. Hm, really? If that were true in Erlang as it > > stands, shouldn't I be able to write it this way? > > > > Fact = fun (0) -> 1; (N) -> N*''(N-1) end. > > > > Looks like it's not quite that simple. It compiles, but it doesn't know > > what module to look in for '', when it comes time to execute. In the > > shell, I get an error indicating that it tried to resolve ''/1 as a > > shell command. Even if I put it in a .erl file and compile it, there's > > no obvious way to tell the compiler what module to look in. ?MODULE:'' > > doesn't work. Nor does '':'', which I tried just for the hell of it. > > > > What Richard's suggesting appears to require a rigorous re-think of how > > scopes are defined in Erlang. What I'm suggesting amounts to simply > > asking the compiler to do some of your tedious keying for you. > > > > -michael turner > > > > > > On Wed, May 18, 2011 at 6:16 PM, Michael Turner < > > michael.eugene.turner@REDACTED> wrote: > > > > I can say > > > > fun (1)->2; > > (2)->1 > > end > > > > but, oddly, I can't define a named function in the analogous way, > > e.g.: > > > > factorial > > (1) -> 1; > > (N) -> N*factorial(N-1). > > > > gives me a syntax error. I find the latter more readable than > > > > factorial(1) -> 1; > > factorial(2) -> N*fact(N-1). > > > > It's also less to type and to read, which is consistent with the > > DRY principle ("Don't Repeat Yourself"). And it lends itself to > > reading a function definition as a set of cases. I think for Erlang > > newbies, it should therefore would be preferred: it helps > > underscore the pattern-matching style of Erlang function > > invocation. > > > > It also looks a *little* bit more like the mathematical convention > > for defining these sorts of functions, where you have "f(x) = ", > > centered vertically to the left of a big left "{" that (left-) > > encloses the list of expression/parameter-condition pairs in a > > two-column format, e.g., > > > > http://cnx.org/content/m29517/latest/Picture%2047.png > > > > So there's a (weak) argument from the Principle of Least Surprise > > here as well. > > > > It seems to me that, if anything, this requires only a > > *simplification* of the Erlang parser. That leaves only one obvious > > objection: would any existing code break if Erlang syntax were > > altered to allow this? > > > > -michael turner > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > - -- > Parnell "ixmatus" Springmeyer (http://ixmat.us) > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > > iQEcBAEBAgAGBQJN0+XsAAoJEPvtlbpI1POLEXEIAJrjAGVTkveBi5/akYNMjBEX > 8wI9twatnXh8sfg2ohGKr3P1hj4jTr9ARrG5wiB9OCArRkBymnjFeY5g2dkBDOhN > aN722l+yDPpUewAM58m0dDoDHjrHXvxF1MJejQJGhQ+Nr9fM+7G+4QIrCN9RvX1S > QTAS+OqOnl8lsS98yvUiXXLB5ehdHcR46Ix6Sq7UwSvqaOKZMoPrzkTtW3VyS5kf > i/uGbPZ1I3KQJYRShk2QlLis/tpXGtLDnYc1E5uADqeClDXy5Au6LWpNqUjNIiWw > h8I2emcBq5Ur7nivNUYgnVMjg+0qTkQOtttPpOJ25xIYv07L+eMfXneb5nRx4hc= > =GGPU > -----END PGP SIGNATURE----- > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fred.hebert@REDACTED Wed May 18 23:50:29 2011 From: fred.hebert@REDACTED (=?iso-8859-1?Q?Fr=E9d=E9ric_Trottier-H=E9bert?=) Date: Wed, 18 May 2011 17:50:29 -0400 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: Message-ID: <22C3B5AA-485A-4BB5-BCA3-7CBB178CFF30@erlang-solutions.com> On 2011-05-18, at 17:40 PM, Joe Armstrong wrote: > > > > Me, I'd like to say > > L = [{foo, fun(X,Y) -> ... end}, {bar, fun(X) -> ... end}] > > then have couple of new bifs Mod = list_to_mod(L) to compose > a module from a load of funs and mod_to_list to do the inverse. > > > > /Joe > > I think you would enjoy meck then (https://github.com/eproxus/meck): Eshell V5.7.5 (abort with ^G) 1> meck:new(dog). ok 2> meck:expect(dog, bark, fun() -> "Woof!" end). ok 3> dog:bark(). "Woof!" It lets you do that, and it includes more testing facilities (expectations, exceptions, history of calls, etc.), but it has some core features that do what you want. One issue of doing things that way is that it's impossible to do recursion without cheating and basically embedding a y-combinator in your code* *: 4> meck:expect(dog, rec, fun(X) -> 4> F = fun(F,0) -> io:format("~p~n",[0]); 4> (F,Y) -> io:format("~p~n",[Y]), 4> F(F,Y-1) 4> end, 4> F(F,X) 4> end). ok 5> dog:rec(3). 3 2 1 0 ok -- Fred H?bert http://www.erlang-solutions.com From toby@REDACTED Thu May 19 01:09:06 2011 From: toby@REDACTED (Toby Thain) Date: Wed, 18 May 2011 19:09:06 -0400 Subject: [erlang-questions] Erlang Style Guide In-Reply-To: <007501cc1563$701fce60$505f6b20$@com> References: <5DA19A7D-7A10-4A06-B7F9-7CF1F056E52C@dmitriid.com> <007501cc1563$701fce60$505f6b20$@com> Message-ID: <4DD45192.2090402@telegraphics.com.au> On 18/05/11 9:56 AM, David Mercer wrote: > I daresay, if ROK would publish /his/ standards, I?d probably follow > them. Co-signed. --Toby > He?s the guy who puts punctuation at the beginning of a lot of > lines. The way it is now, I just go with what looks good (which means > punctuation at the end of the line), because I can?t be bothered coming > up with rules to follow, but I?m pretty sure ROK has in his head some > self-consistent system that makes sense and makes coding easier. > > > > Actually, I?d probably follow anyone?s formatting rules if someone would > publish some. Maybe /I/ should? > > > > Cheers, > > > > DBM > > > > *From:*erlang-questions-bounces@REDACTED > [mailto:erlang-questions-bounces@REDACTED] *On Behalf Of *Joe Armstrong > *Sent:* Wednesday, May 18, 2011 8:02 AM > *To:* Dmitrii Dimandt > *Cc:* Erlang Questions > *Subject:* Re: [erlang-questions] Erlang Style Guide > > > > > > On Wed, May 18, 2011 at 2:39 PM, Dmitrii Dimandt > wrote: > > This is an excellent guide. However, it mostly deals with language > constructs and programming habits. It would be nice to complement this > with a "writing style" guide that would discuss identation and nesting, > naming conventions etc. > > > > > > > Where to put punctuation, naming etc. is a matter that is discussed with > religious fervor - nobody agrees > here at all ... > > /Joe > > > > > What about this? > > > > http://www.erlang.se/doc/programming_rules.shtml > > On Wed, May 18, 2011 at 2:16 PM, Dmitrii > Dimandt > wrote: > > Hi all! > > > > Is there a more-or-less universally accepted Erlang Style Guide. > SImilar to, say, PEP08 (http://www.python.org/dev/peps/pep-0008/). > > If there isn't, does anyone has a style guide the use? Would you > care to share you style guides with the list? > > Thank you! > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > > -- > Regards, > Alexander > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From steven.charles.davis@REDACTED Thu May 19 01:12:49 2011 From: steven.charles.davis@REDACTED (Steve Davis) Date: Wed, 18 May 2011 16:12:49 -0700 (PDT) Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: Message-ID: <2b09c525-84a1-4723-80a6-19615241934b@h7g2000yqa.googlegroups.com> Since this is the second thread on this issue, I'm assuming you feel very strongly about it. Why not file an EEP? Also you have the option to write a parse transform if you hate it that much. My view remains "if it ain't broke don't fix it", since after a few years of writing erlang programs, I do know that it ain't broke. My respectful 2c. /s On May 18, 9:18?am, Michael Turner wrote: > Another objection raised against this syntax change is that all functional > languages violate DRY in this manner, so it's OK if Erlang does it too. This > is a Principle of Least Surprise argument, and not bad as far as it goes. > But how far does it go? > > Erlang will have a better chance of greater success and survival if you > consider your recruitment base to be the overwhelming majority of > programmers. And from what I can tell, > > ?http://www.langpop.com > > the overwhelming majority of programmers have no experience to speak of, > when it comes to functional programming languages. Appealing to the > "cross-training" benefit of coming from other FP languages seems like a > pretty weak argument. Especially since all I'm asking for here is syntactic > consistency *within* Erlang -- a PLoS argument in itself. > > Richard O'Keefe suggests that the syntactic consistency goal is better met > by allowing a kind of limited-scope special-case fun name, permitting, e.g. > > ? Fact = fun F(0) -> 1; F(N) -> N*F(N-1) end. > > I could get behind that too, but I don't follow his reasoning from syntactic > consistency, which is apparently that an unnamed fun has a name, it's just > the degenerate case of a name. ?It's really there. We just can't see it. Hm, > really? If that were true in Erlang as it stands, shouldn't I be able to > write it this way? > > ? Fact = fun (0) -> 1; (N) -> N*''(N-1) end. > > Looks like it's not quite that simple. It compiles, but it doesn't know what > module to look in for '', when it comes time to execute. In the shell, I get > an error indicating that it tried to resolve ''/1 as a shell command. Even > if I put it in a .erl file and compile it, there's no obvious way to tell > the compiler what module to look in. ?MODULE:'' doesn't work. Nor does > '':'', which I tried just for the hell of it. > > What Richard's suggesting appears to require a rigorous re-think of how > scopes are defined in Erlang. What I'm suggesting amounts to simply asking > the compiler to do some of your tedious keying for you. > > -michael turner > > On Wed, May 18, 2011 at 6:16 PM, Michael Turner < > > > > > > > > michael.eugene.tur...@REDACTED> wrote: > > I can say > > > ? ?fun (1)->2; > > ? ? ? ? (2)->1 > > ? ?end > > > but, oddly, I can't define a named function in the analogous way, e.g.: > > > ? ?factorial > > ? ? ?(1) -> 1; > > ? ? ?(N) -> N*factorial(N-1). > > > gives me a syntax error. I find the latter more readable than > > > ? ?factorial(1) -> 1; > > ? ?factorial(2) -> N*fact(N-1). > > > It's also less to type and to read, which is consistent with the DRY > > principle ("Don't Repeat Yourself"). ?And it lends itself to reading a > > function definition as a set of cases. I think for Erlang newbies, it should > > therefore would be preferred: it helps underscore the pattern-matching style > > of Erlang function invocation. > > > It also looks a *little* bit more like the mathematical convention for > > defining these sorts of functions, where you have "f(x) = ", centered > > vertically to the left of a big left "{" that (left-)encloses the list of > > expression/parameter-condition pairs in a two-column format, e.g., > > > ?http://cnx.org/content/m29517/latest/Picture%2047.png > > > So there's a (weak) argument from the Principle of Least Surprise here as > > well. > > > It seems to me that, if anything, this requires only a *simplification* of > > the Erlang parser. That leaves only one obvious objection: would any > > existing code break if Erlang syntax were altered to allow this? > > > -michael turner > > > > _______________________________________________ > erlang-questions mailing list > erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions From dennis.duong.646@REDACTED Thu May 19 02:05:07 2011 From: dennis.duong.646@REDACTED (ag3nt911) Date: Wed, 18 May 2011 17:05:07 -0700 (PDT) Subject: [erlang-questions] gen_server:call and hibernate Message-ID: <1305763507064-3534336.post@n4.nabble.com> Dear list, >From the facebook slides of their chat system architecture, eugene mentioned that "Hibernation ? Drastically shrink memory usage with erlang:hibernate/3 ? Throws away the call stack ? Minimizes the heap ? Enters a wait state for new messages ? ?Jumps? into a passed-in function for a received message ? Perfect for a long-running, idling HTTP request handler ? But ... not compatible with gen_server:call (and gen_server:reply) ? gen_server:call has its own receive() loop ? hibernate() doesn?t support have an explicit timeout ? Fixed with a few hours and a look at gen.erl" " It took me a while to understand what he was saying. He even responded to another persons question about this: "The incompatibility is on the client side (gen:call), not the server side (gen_server:handle_call). There's a receive() loop inside gen:call that prevents a client from hibernating between dispatching the $call message and getting back the gen_server:reply()." I want to be able to hibernate the calling process after making a call to the gen_server process but I can't seem to think of or know how to work around this in an elegant way. I'm also not sure where to begin to hack gen.erl to do this if it is possible. Does anybody have a solution to my predicament here? -- View this message in context: http://erlang.2086793.n4.nabble.com/gen-server-call-and-hibernate-tp3534336p3534336.html Sent from the Erlang Questions mailing list archive at Nabble.com. From michael.eugene.turner@REDACTED Thu May 19 06:28:03 2011 From: michael.eugene.turner@REDACTED (Michael Turner) Date: Thu, 19 May 2011 13:28:03 +0900 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: <2b09c525-84a1-4723-80a6-19615241934b@h7g2000yqa.googlegroups.com> References: <2b09c525-84a1-4723-80a6-19615241934b@h7g2000yqa.googlegroups.com> Message-ID: On Thu, May 19, 2011 at 8:12 AM, Steve Davis wrote: > Since this is the second thread on this issue, I'm assuming you feel > very strongly about it. Why not file an EEP? > Pedantically: it's not an extension. Arguably, it's really just a bug, to be filed as "parser fails to parse function definitions consistently." If someone then tried to assert this inconsistency is an official inconsistency, because Erlang is *defined* this way, I'd ask, "where?" Where is the official document that sets forth what Erlang's syntax is? Is it that same document that describes the syntax of "let", a keyword reserved for use in some future that never seems to arrive? > Also you have the option to write a parse transform if you hate it > that much. > I don't hate it. I just don't see the point of the way things are now. And a parse transform would be enormous. A fix to the Erlang parser would probably be a few lines (leaving the parser shorter, no doubt). > My view remains "if it ain't broke don't fix it", since after a few > years of writing erlang programs, I do know that it ain't broke. > Brokenness is not the only fault a system can have. As far as I can tell, the worst consequence of the proposed change is that you'd start seeing code that looked like this: fact (0) -> 1; (N) -> N*fact(N-1). which is transparently obvious. So the argument that the change somehow makes code less readable makes no sense to me. -michael turner > On May 18, 9:18 am, Michael Turner > wrote: > > Another objection raised against this syntax change is that all > functional > > languages violate DRY in this manner, so it's OK if Erlang does it too. > This > > is a Principle of Least Surprise argument, and not bad as far as it goes. > > But how far does it go? > > > > Erlang will have a better chance of greater success and survival if you > > consider your recruitment base to be the overwhelming majority of > > programmers. And from what I can tell, > > > > http://www.langpop.com > > > > the overwhelming majority of programmers have no experience to speak of, > > when it comes to functional programming languages. Appealing to the > > "cross-training" benefit of coming from other FP languages seems like a > > pretty weak argument. Especially since all I'm asking for here is > syntactic > > consistency *within* Erlang -- a PLoS argument in itself. > > > > Richard O'Keefe suggests that the syntactic consistency goal is better > met > > by allowing a kind of limited-scope special-case fun name, permitting, > e.g. > > > > Fact = fun F(0) -> 1; F(N) -> N*F(N-1) end. > > > > I could get behind that too, but I don't follow his reasoning from > syntactic > > consistency, which is apparently that an unnamed fun has a name, it's > just > > the degenerate case of a name. It's really there. We just can't see it. > Hm, > > really? If that were true in Erlang as it stands, shouldn't I be able to > > write it this way? > > > > Fact = fun (0) -> 1; (N) -> N*''(N-1) end. > > > > Looks like it's not quite that simple. It compiles, but it doesn't know > what > > module to look in for '', when it comes time to execute. In the shell, I > get > > an error indicating that it tried to resolve ''/1 as a shell command. > Even > > if I put it in a .erl file and compile it, there's no obvious way to tell > > the compiler what module to look in. ?MODULE:'' doesn't work. Nor does > > '':'', which I tried just for the hell of it. > > > > What Richard's suggesting appears to require a rigorous re-think of how > > scopes are defined in Erlang. What I'm suggesting amounts to simply > asking > > the compiler to do some of your tedious keying for you. > > > > -michael turner > > > > On Wed, May 18, 2011 at 6:16 PM, Michael Turner < > > > > > > > > > > > > > > > > michael.eugene.tur...@REDACTED> wrote: > > > I can say > > > > > fun (1)->2; > > > (2)->1 > > > end > > > > > but, oddly, I can't define a named function in the analogous way, e.g.: > > > > > factorial > > > (1) -> 1; > > > (N) -> N*factorial(N-1). > > > > > gives me a syntax error. I find the latter more readable than > > > > > factorial(1) -> 1; > > > factorial(2) -> N*fact(N-1). > > > > > It's also less to type and to read, which is consistent with the DRY > > > principle ("Don't Repeat Yourself"). And it lends itself to reading a > > > function definition as a set of cases. I think for Erlang newbies, it > should > > > therefore would be preferred: it helps underscore the pattern-matching > style > > > of Erlang function invocation. > > > > > It also looks a *little* bit more like the mathematical convention for > > > defining these sorts of functions, where you have "f(x) = ", centered > > > vertically to the left of a big left "{" that (left-)encloses the list > of > > > expression/parameter-condition pairs in a two-column format, e.g., > > > > > http://cnx.org/content/m29517/latest/Picture%2047.png > > > > > So there's a (weak) argument from the Principle of Least Surprise here > as > > > well. > > > > > It seems to me that, if anything, this requires only a *simplification* > of > > > the Erlang parser. That leaves only one obvious objection: would any > > > existing code break if Erlang syntax were altered to allow this? > > > > > -michael turner > > > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questi...@REDACTED:// > erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.eugene.turner@REDACTED Thu May 19 06:39:56 2011 From: michael.eugene.turner@REDACTED (Michael Turner) Date: Thu, 19 May 2011 13:39:56 +0900 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: Message-ID: Joe, with all due respect, I think you've misinterpreted DRY. It's not a matter of writing something again because you can't find where it's already implemented. In fact, the canonical example of DRY is to write something that works for one case, and then, rather than define it as a function, template or macro, and invoke it with varying parameters, instead copy-paste-mutate for each case. In fact, the most common violations of DRY are *precisely* when you know where the repeated code is, either because you've just found it or because you've just written it. "DRY says that every piece of system knowledge should have one authoritative, unambiguous representation." http://www.artima.com/intv/dry.html Erlang function definition syntax has two representations in the parser -- for no good reason I can see. Why? "Changing syntax is *incredibly difficult* project managers get apoplectic at the thought of retesting million lines of code -" No existing code will use the syntax I suggest. So how can any of it break? I have yet to get an answer: what could this proposed change possibly break, even *theoretically*? -michael turner On Thu, May 19, 2011 at 6:47 AM, Joe Armstrong wrote: > > > On Wed, May 18, 2011 at 5:29 PM, Parnell Springmeyer wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Sorry, but Erlang doesn't *need* a better chance of survival. This >> language is not just growing, it's booming. Changing core language >> features that are solid, well thought out, and non-harmful (in other >> words, they are, FEATURES) to make it more "adoptable" is a lot like >> someone saying, "you have to quit that quirky smile so other people will >> like you more." >> > > Languages survive forever once they get to the point where > > 1) legacy applications in the language still earn money > 2) it costs more to convert to a new language than maintain the > existing app in the old language > > Erlang reached this point, many years ago. > > Right now Erlang companies have a commercial advantage > over non-erlang companies and so there is not much point in > trying to spread the language further - you just loose your commercial > advantage. > > /Joe > > >> >> Sometimes, yes, there are features in a language that could use >> refinement - but many times, in a mature language, the ratio between >> need and usefulness in refining a feature further, drops significantly. >> >> Instead of changing something that is solid, educate the people that >> have a hard time grasping it, build killer example applications that >> exhibit the quirky style and idioms to a T - people /will/ follow it, >> almost to a religious end. >> >> That's actually what I like about Erlang the most, the documentation has >> so many gems in it like the efficiency guide (where many common idioms >> are expressed with clear DO and DON'T DO examples) and style guide. >> >> RE: syntactic consistency: Erlang's syntax *IS* consistent - it's more >> consistent than many languages I've touched. >> >> Is Erlang easy for a Perl programmer? I bet not, and Perl's syntax is >> less consistent than Erlang's is in my opinion. The issue you are >> attempting to get at is (again) an educational and experience one, not >> something that is inherently wrong with the language or its expression >> itself. >> >> I'm actually baffled by the efforts people are putting into different >> Erlang VM frontends that look like Ruby or Python. Good on them for >> exercising the freedom of open source but /why/? Erlang's syntax is >> almost beautiful to me now after using it, it's so well suited for what >> Erlang is good at! >> >> Erlang isn't that great for general purpose programming - you use >> Python, Ruby, C, D, etc... for stuff like that. Erlang is great at fault >> tolerance, easy parallelism (which isn't easy!), and hot code >> loading. Features that are so difficult to do in the traditional >> imperative environment that (to date) I have not seen a single >> implementation of any one of those features that even approaches the >> completeness of Erlang's. >> >> Michael Turner writes: >> >> > Another objection raised against this syntax change is that all >> > functional languages violate DRY in this manner, so it's OK if Erlang >> > does it too. This is a Principle of Least Surprise argument, and not >> > bad as far as it goes. But how far does it go? >> > >> > Erlang will have a better chance of greater success and survival if you >> > consider your recruitment base to be the overwhelming majority of >> > programmers. And from what I can tell, >> > >> > http://www.langpop.com >> > >> > the overwhelming majority of programmers have no experience to speak >> > of, when it comes to functional programming languages. Appealing to the >> > "cross-training" benefit of coming from other FP languages seems like a >> > pretty weak argument. Especially since all I'm asking for here is >> > syntactic consistency *within* Erlang -- a PLoS argument in itself. >> > >> > Richard O'Keefe suggests that the syntactic consistency goal is better >> > met by allowing a kind of limited-scope special-case fun name, >> > permitting, e.g. >> > >> > Fact = fun F(0) -> 1; F(N) -> N*F(N-1) end. >> > >> > I could get behind that too, but I don't follow his reasoning from >> > syntactic consistency, which is apparently that an unnamed fun has a >> > name, it's just the degenerate case of a name. It's really there. We >> > just can't see it. Hm, really? If that were true in Erlang as it >> > stands, shouldn't I be able to write it this way? >> > >> > Fact = fun (0) -> 1; (N) -> N*''(N-1) end. >> > >> > Looks like it's not quite that simple. It compiles, but it doesn't know >> > what module to look in for '', when it comes time to execute. In the >> > shell, I get an error indicating that it tried to resolve ''/1 as a >> > shell command. Even if I put it in a .erl file and compile it, there's >> > no obvious way to tell the compiler what module to look in. ?MODULE:'' >> > doesn't work. Nor does '':'', which I tried just for the hell of it. >> > >> > What Richard's suggesting appears to require a rigorous re-think of how >> > scopes are defined in Erlang. What I'm suggesting amounts to simply >> > asking the compiler to do some of your tedious keying for you. >> > >> > -michael turner >> > >> > >> > On Wed, May 18, 2011 at 6:16 PM, Michael Turner < >> > michael.eugene.turner@REDACTED> wrote: >> > >> > I can say >> > >> > fun (1)->2; >> > (2)->1 >> > end >> > >> > but, oddly, I can't define a named function in the analogous way, >> > e.g.: >> > >> > factorial >> > (1) -> 1; >> > (N) -> N*factorial(N-1). >> > >> > gives me a syntax error. I find the latter more readable than >> > >> > factorial(1) -> 1; >> > factorial(2) -> N*fact(N-1). >> > >> > It's also less to type and to read, which is consistent with the >> > DRY principle ("Don't Repeat Yourself"). And it lends itself to >> > reading a function definition as a set of cases. I think for Erlang >> > newbies, it should therefore would be preferred: it helps >> > underscore the pattern-matching style of Erlang function >> > invocation. >> > >> > It also looks a *little* bit more like the mathematical convention >> > for defining these sorts of functions, where you have "f(x) = ", >> > centered vertically to the left of a big left "{" that (left-) >> > encloses the list of expression/parameter-condition pairs in a >> > two-column format, e.g., >> > >> > http://cnx.org/content/m29517/latest/Picture%2047.png >> > >> > So there's a (weak) argument from the Principle of Least Surprise >> > here as well. >> > >> > It seems to me that, if anything, this requires only a >> > *simplification* of the Erlang parser. That leaves only one obvious >> > objection: would any existing code break if Erlang syntax were >> > altered to allow this? >> > >> > -michael turner >> > >> > _______________________________________________ >> > erlang-questions mailing list >> > erlang-questions@REDACTED >> > http://erlang.org/mailman/listinfo/erlang-questions >> >> - -- >> Parnell "ixmatus" Springmeyer (http://ixmat.us) >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG/MacGPG2 v2.0.17 (Darwin) >> Comment: GPGTools - http://gpgtools.org >> >> iQEcBAEBAgAGBQJN0+XsAAoJEPvtlbpI1POLEXEIAJrjAGVTkveBi5/akYNMjBEX >> 8wI9twatnXh8sfg2ohGKr3P1hj4jTr9ARrG5wiB9OCArRkBymnjFeY5g2dkBDOhN >> aN722l+yDPpUewAM58m0dDoDHjrHXvxF1MJejQJGhQ+Nr9fM+7G+4QIrCN9RvX1S >> QTAS+OqOnl8lsS98yvUiXXLB5ehdHcR46Ix6Sq7UwSvqaOKZMoPrzkTtW3VyS5kf >> i/uGbPZ1I3KQJYRShk2QlLis/tpXGtLDnYc1E5uADqeClDXy5Au6LWpNqUjNIiWw >> h8I2emcBq5Ur7nivNUYgnVMjg+0qTkQOtttPpOJ25xIYv07L+eMfXneb5nRx4hc= >> =GGPU >> -----END PGP SIGNATURE----- >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yaohui1984@REDACTED Thu May 19 07:07:26 2011 From: yaohui1984@REDACTED (=?ISO-8859-1?B?eWFvaHVp?=) Date: Thu, 19 May 2011 13:07:26 +0800 Subject: [erlang-questions] About Environment variable ERL_MAX_PORTS Message-ID: It meas the maximum number of simultaneously open Erlang ports , but what's Erlang ports? If i want a 500k concurrent connections, this variable has to be set to 500k? -------------- next part -------------- An HTML attachment was scrubbed... URL: From small@REDACTED Thu May 19 07:43:38 2011 From: small@REDACTED (Des Small) Date: Thu, 19 May 2011 07:43:38 +0200 (CEST) Subject: [erlang-questions] [EUG-NL] Erlang Users' Group Netherlands? In-Reply-To: References: Message-ID: On Wed, 18 May 2011, Ahmed Omar wrote: > Nice, and I'm in RotterdamAnybody else? Well, in principle. I live in Groningen and work in Dwingeloo so the chances of me ever showing up for an event in the Randstad are not great. Cheers, Des -- Des Small, Scientific Programmer, JIVE Contact details on http://www.jive.nl/~small From small@REDACTED Thu May 19 07:54:30 2011 From: small@REDACTED (Des Small) Date: Thu, 19 May 2011 07:54:30 +0200 (CEST) Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: Message-ID: On Wed, 18 May 2011, Daniel Goertzen wrote: > I think this is a key issue here: multi-clause funs just don't happen all that often. ? They happen to me all the time. Every time I write a recursive function, I first write the clause for the base case, then a clause (or clauses) for the others. I don't currently wish for a different syntax, though. Cheers, Des -- Des Small, Scientific Programmer, JIVE Contact details on http://www.jive.nl/~small From michael.eugene.turner@REDACTED Thu May 19 08:36:01 2011 From: michael.eugene.turner@REDACTED (Michael Turner) Date: Thu, 19 May 2011 15:36:01 +0900 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: Message-ID: "I don't currently wish for a different syntax ..." I'm sorry if you got the impression that you'd have to change, under what's proposed here. You wouldn't. It is (until I'm informed otherwise) backward compatible. -michael turner On Thu, May 19, 2011 at 2:54 PM, Des Small wrote: > On Wed, 18 May 2011, Daniel Goertzen wrote: > > I think this is a key issue here: multi-clause funs just don't happen all >> that often. >> > > They happen to me all the time. Every time I write a recursive function, I > first write the clause for the base case, then a clause (or clauses) for the > others. > > I don't currently wish for a different syntax, though. > > Cheers, > > Des > -- > Des Small, > Scientific Programmer, JIVE > Contact details on http://www.jive.nl/~small > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.eugene.turner@REDACTED Thu May 19 08:48:35 2011 From: michael.eugene.turner@REDACTED (Michael Turner) Date: Thu, 19 May 2011 15:48:35 +0900 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: Message-ID: "... multi-clause funs just don't happen all that often ...." The issue isn't multi-clause funs -- to maintain backward compatibility, if nothing else, they'd have to retain their current syntax anyway. (Besides: if multi-clause funs were more clearly documented, they might be better-known and you might have seen them sooner in other people's code.) In any case, multi-clause named functions are very common -- I'd say about one third of the functions I write are multi-clause, and something close to that ratio seems typical of most Erlang code. All I'm proposing is that we should have the option of using the syntax of multi-clause funs in named functions as well -- so that you only have to write the name once, among other benefits. -michael turner On Thu, May 19, 2011 at 1:17 AM, Daniel Goertzen < dang@REDACTED> wrote: > > > On Wed, May 18, 2011 at 11:08 AM, Michael Turner < > michael.eugene.turner@REDACTED> wrote > > "I didn't ask that question until I *stumbled* on the extended syntax for > funs; I didn't know about it before. The current documentation makes it hard > to find." > > > > > I think this is a key issue here: multi-clause funs just don't happen all > that often. It was very late in my Erlang learning experience that I found > the need for multi-clause funs, and I easily found the documentation at the > time. I did notice the syntax inconsistency, but didn't care. Anyway, it > is often a good idea to break funs out into full functions to reduce nesting > and facilitate tracing. Lots of funs make programs hard to debug. > > Dan. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.kleberg@REDACTED Thu May 19 08:50:37 2011 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Thu, 19 May 2011 08:50:37 +0200 Subject: [erlang-questions] About Environment variable ERL_MAX_PORTS In-Reply-To: References: Message-ID: <1305787837.5192.2.camel@seasc1137> Greetings, If I may assume that you mean network connections the manual (http://erlang.org/doc/efficiency_guide/advanced.html#id67006) says: "The maximum number of simultaneously open files and sockets depend on the maximum number of Erlang ports available, and operating system specific settings and limits." So you need at least 500k ports and that the OS allows you to use 500k for sockets. bengt On Thu, 2011-05-19 at 07:07 +0200, yaohui wrote: > It meas the maximum number of simultaneously open Erlang ports , but > what's Erlang ports? > > If i want a 500k concurrent connections, this variable has to be set > to 500k? From paolo.negri@REDACTED Thu May 19 09:23:52 2011 From: paolo.negri@REDACTED (Paolo Negri) Date: Thu, 19 May 2011 09:23:52 +0200 Subject: [erlang-questions] memory allocation and constant pool behavior Message-ID: Dear list Given the following module -module(example). -export([get_configuration/1]). get_configuration(Position) -> Configurations = {{2,3}, {4,1}, {9,7}, {2,1}}, ConfigurationElement = element(Position, Configurations), Constant = {10, 9}, {ConfigurationElement, Constant}. I'm trying to understand what happens exactly from a memory allocation point of view when the function get_configuration gets called, here's an example call 2> Value = example:get_configuration(2). {{4,1},{10,9}} my understanding is that Configurations and Constant will reside in the constant pool so they won't be allocated at each single execution, but what I'm looking for is the memory overhead of building the resulting tuple. According to the efficiency guide [1] the size of the resulting tuple is 2 words for the containing tuple 4 words for the the inner tuples 4 words for the integers which results in 10 words total, but how many new words will actually be allocated at the moment of invoking the function? 1. http://www.erlang.org/doc/efficiency_guide/advanced.html Thanks for your answers. Paolo From marc@REDACTED Thu May 19 10:03:19 2011 From: marc@REDACTED (Marc Worrell) Date: Thu, 19 May 2011 10:03:19 +0200 Subject: [erlang-questions] [EUG-NL] Erlang Users' Group Netherlands? In-Reply-To: References: Message-ID: <80572051-CA10-48BC-86B2-BDB6D33BACFF@worrell.nl> We are with a small group here in A'dam working on Zotonic (and MaxClass). I guess everyone would be interested. Groet, Marc On 19 mei 2011, at 07:43, Des Small wrote: > On Wed, 18 May 2011, Ahmed Omar wrote: > >> Nice, and I'm in RotterdamAnybody else? > > Well, in principle. I live in Groningen and work in Dwingeloo so the chances of me ever showing up for an event in the Randstad are not great. > > Cheers, > > Des > -- > Des Small, > Scientific Programmer, JIVE > Contact details on http://www.jive.nl/~small > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From spawn.think@REDACTED Thu May 19 10:31:25 2011 From: spawn.think@REDACTED (Ahmed Omar) Date: Thu, 19 May 2011 10:31:25 +0200 Subject: [erlang-questions] [EUG-NL] Erlang Users' Group Netherlands? In-Reply-To: <80572051-CA10-48BC-86B2-BDB6D33BACFF@worrell.nl> References: <80572051-CA10-48BC-86B2-BDB6D33BACFF@worrell.nl> Message-ID: Great, I created the group : http://www.linkedin.com/groups?mostPopular=&gid=3917956 Please join and let's start discussing next steps! On Thu, May 19, 2011 at 10:03 AM, Marc Worrell wrote: > We are with a small group here in A'dam working on Zotonic (and MaxClass). > I guess everyone would be interested. > > Groet, Marc > > > > On 19 mei 2011, at 07:43, Des Small wrote: > > > On Wed, 18 May 2011, Ahmed Omar wrote: > > > >> Nice, and I'm in RotterdamAnybody else? > > > > Well, in principle. I live in Groningen and work in Dwingeloo so the > chances of me ever showing up for an event in the Randstad are not great. > > > > Cheers, > > > > Des > > -- > > Des Small, > > Scientific Programmer, JIVE > > Contact details on http://www.jive.nl/~small > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think -------------- next part -------------- An HTML attachment was scrubbed... URL: From steven.charles.davis@REDACTED Thu May 19 10:32:26 2011 From: steven.charles.davis@REDACTED (Steve Davis) Date: Thu, 19 May 2011 03:32:26 -0500 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: <2b09c525-84a1-4723-80a6-19615241934b@h7g2000yqa.googlegroups.com> Message-ID: <4DD4D59A.6080708@gmail.com> Hi Michael, This example is far from convincing. Have you tried this for yourself on any but the most trivial case, and done a genuine comparison? If you had, I think you would actually agree with my point that it would end up being less readable. regards, /s On 5/18/2011 11:28 PM, Michael Turner wrote: > Brokenness is not the only fault a system can have. As far as I can > tell, the worst consequence of the proposed change is that you'd start > seeing code that looked like this: > > fact > (0) -> 1; > (N) -> N*fact(N-1). > > which is transparently obvious. So the argument that the change somehow > makes code less readable makes no sense to me. > > -michael turner From watson.timothy@REDACTED Thu May 19 10:35:07 2011 From: watson.timothy@REDACTED (Tim Watson) Date: Thu, 19 May 2011 09:35:07 +0100 Subject: [erlang-questions] gen_server:call and hibernate In-Reply-To: <1305763507064-3534336.post@n4.nabble.com> References: <1305763507064-3534336.post@n4.nabble.com> Message-ID: > "The incompatibility is on the client side (gen:call), not the server > side (gen_server:handle_call). There's a receive() loop inside > gen:call that prevents a client from hibernating between dispatching > the $call message and getting back the gen_server:reply()." > > I want to be able to hibernate the calling process after making a call to > the gen_server process but I can't seem to think of or know how to work > around this in an elegant way. I'm also not sure where to begin to hack > gen.erl to do this if it is possible. > > Does anybody have a solution to my predicament here? I'm not sure about this exact use case, but have you looked at gen_server2 (from rabbitmq) at all? It handles timeouts differently and drains the message queue before invoking callbacks (which optimisation I believe has made it into gen.erl proper now). http://hg.rabbitmq.com/rabbitmq-server/file/dc753bc0c54e/src/gen_server2.erl From steven.charles.davis@REDACTED Thu May 19 10:48:33 2011 From: steven.charles.davis@REDACTED (Steve Davis) Date: Thu, 19 May 2011 03:48:33 -0500 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: <4DD4D59A.6080708@gmail.com> References: <2b09c525-84a1-4723-80a6-19615241934b@h7g2000yqa.googlegroups.com> <4DD4D59A.6080708@gmail.com> Message-ID: <4DD4D961.5000703@gmail.com> Out of interest, I tried it on one of my own modules. Your way: https://gist.github.com/980420 The highway: https://github.com/komone/qrcode/blob/master/src/base32.erl In order to make your way less confusing, as the pattern matching entry points to the function were extremely un-obvious, and in the spirit of making it work I tried "double indent". Double indented: https://gist.github.com/980412 For me, either way, the intention is harder to read, and/or forces me to focus on/put in a bunch of white space. What do you think? On 5/19/2011 3:32 AM, Steve Davis wrote: > Hi Michael, > > This example is far from convincing. Have you tried this for yourself on > any but the most trivial case, and done a genuine comparison? If you > had, I think you would actually agree with my point that it would end up > being less readable. > > regards, > /s > > On 5/18/2011 11:28 PM, Michael Turner wrote: >> Brokenness is not the only fault a system can have. As far as I can >> tell, the worst consequence of the proposed change is that you'd start >> seeing code that looked like this: >> >> fact >> (0) -> 1; >> (N) -> N*fact(N-1). >> >> which is transparently obvious. So the argument that the change somehow >> makes code less readable makes no sense to me. >> >> -michael turner From steve@REDACTED Thu May 19 11:02:20 2011 From: steve@REDACTED (Steve Strong) Date: Thu, 19 May 2011 11:02:20 +0200 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: <4DD4D961.5000703@gmail.com> References: <2b09c525-84a1-4723-80a6-19615241934b@h7g2000yqa.googlegroups.com> <4DD4D59A.6080708@gmail.com> <4DD4D961.5000703@gmail.com> Message-ID: <9D708DA9806145C5AD7041ADAAA9B0DF@srstrong.com> I hadn't taken the time to do the exercise myself, but your results don't surprise me. Although repeating the function name doesn't strictly comply with DRY, I personally think that it improves readability of all but the most trivial examples. And, for me at least, readability trumps pretty much every other principle (outside of correctness, obviously). DRY is an important concept but, as with most such things, you need to know when to stop, and for me this would be a step too far. If I took some (most) of my gen_servers and removed the text "handle_call" from all but the first clause, navigating the code would become significantly harder. A simple search would not jump me between clauses, I would instead need to rely on tool support for this very common use-case. Obviously, readability is a subjective thing and others may disagree. But if I had a vote, then I think there are other areas of the language where minor tweaks would have much greater benefits, such as allowing trailing commas on lists as Joe raised earlier. I understand that your suggestion would allow both options, but unless the compiler team have infinite resources then I would put non-duplication of function names pretty near the bottom of the todo list. As others have said, if this is such a big thing for you, then write a front-end to do the transform? Cheers, Steve -- Steve Strong, Director, id3as twitter.com/srstrong On Thursday, 19 May 2011 at 10:48, Steve Davis wrote: > Out of interest, I tried it on one of my own modules. > > Your way: https://gist.github.com/980420 > The highway: https://github.com/komone/qrcode/blob/master/src/base32.erl > > In order to make your way less confusing, as the pattern matching entry > points to the function were extremely un-obvious, and in the spirit of > making it work I tried "double indent". > Double indented: https://gist.github.com/980412 > > For me, either way, the intention is harder to read, and/or forces me to > focus on/put in a bunch of white space. > > What do you think? > > On 5/19/2011 3:32 AM, Steve Davis wrote: > > Hi Michael, > > > > This example is far from convincing. Have you tried this for yourself on > > any but the most trivial case, and done a genuine comparison? If you > > had, I think you would actually agree with my point that it would end up > > being less readable. > > > > regards, > > /s > > > > On 5/18/2011 11:28 PM, Michael Turner wrote: > > > Brokenness is not the only fault a system can have. As far as I can > > > tell, the worst consequence of the proposed change is that you'd start > > > seeing code that looked like this: > > > > > > fact > > > (0) -> 1; > > > (N) -> N*fact(N-1). > > > > > > which is transparently obvious. So the argument that the change somehow > > > makes code less readable makes no sense to me. > > > > > > -michael turner > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimo+erlang-questions@REDACTED Thu May 19 11:03:16 2011 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Thu, 19 May 2011 11:03:16 +0200 Subject: [erlang-questions] 'reply-to' header in this mailing list In-Reply-To: References: <688144131.198481305727593991.JavaMail.root@zimbra> <600128661.198501305727597470.JavaMail.root@zimbra> Message-ID: <20110519090316.GA27904@erix.ericsson.se> On Wed, May 18, 2011 at 08:11:17AM -0600, Jack Moffitt wrote: > > How about we completely side-step the whole issue and re-structure the > > various erlang mailing lists a forum instead? And by choosing one of the > > common and free forum packages we will automatically get a standard (in the > > sense of being common and much used) behaviour. > > I really dislike forums. it's very easy for me to rapidly read and > reply to any topics on a mailing list, but with a forum I have to 1) > visit a particular page 2) manually click around. I much prefer having > things in an email client which is optimized for the job. > > The only advantage to forums in my opinion is that the archives tend > to be much better than mailing list archives. The archive is a plus for a forum. There does not seem to be any religious user fractions disaggreing on how forums should behave. That is also a plus. Free forum packages often means PHP, MySQL or other sysadm hazzles. They are more complicated than a mailing list. That is a minus for a forum (from my point of view). There is of course other party forum hosting, but they we loose control of the forum archives... > > jack. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From raimo+erlang-questions@REDACTED Thu May 19 11:37:46 2011 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Thu, 19 May 2011 11:37:46 +0200 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: <1930B4D4-54DD-4F80-ACDE-BBE983315E64@hates.ms> Message-ID: <20110519093746.GB27904@erix.ericsson.se> On Thu, May 19, 2011 at 01:50:33AM +0900, Michael Turner wrote: > I'm still waiting for the answer to the real showstopper question: would any > existing code break, under my proposal? > > -michael turner > I can not think of any existing code that would break, but there are others that have weirder imagination than me. But how interesting is whether existing code would break or not? One nice thing with Erlang for me is that it is not like Perl; there seldom seldom many ways to do it (syntacticly). The current compromise and limitation of having to write the function name for every clause for regular function and not writing any function name for funs I think is very good. It encourages short funs and makes it easier to read long functions with many clauses. If you restructure your code, move around clauses often you run into a compilation error when you have messed up clauses between functions. If you would remove the requirement of a function name on every clause you would increase the possibility of getting completely incorrect code through the compiler since it is enough that the arity is the same between the clauses; you can accidentally paste in a totally unrelated clause from some other function and not discover it until it crashes in the field, provided testing is incomplete (which it mostly is). It would, as others have pointed out, also be much harder to jump into a module and _know_ what the clause does since the function's name can be pages away. That would encourage no more than page-long functions instead of no more than page-long clauses and I sincerely prefere the latter. In short. I think the impact on readability and programmer's common mistake preventions clearly does not motivate the change. The possible benefits are minor. -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From ulf.wiger@REDACTED Thu May 19 11:43:30 2011 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Thu, 19 May 2011 11:43:30 +0200 Subject: [erlang-questions] gen_server:call and hibernate In-Reply-To: <1305763507064-3534336.post@n4.nabble.com> References: <1305763507064-3534336.post@n4.nabble.com> Message-ID: <271ABE52-4C73-4FB5-B35F-BC25BBAE8413@erlang-solutions.com> On 19 May 2011, at 02:05, ag3nt911 wrote: > I want to be able to hibernate the calling process after making a call to > the gen_server process but I can't seem to think of or know how to work > around this in an elegant way. I'm also not sure where to begin to hack > gen.erl to do this if it is possible. I presume your client expects to wait a very long time then? :) The "throws away the call stack" part is important to consider. Normally, you'd want a gen_server:call/2 to raise debuggable exceptions if something goes wrong. Hibernating in this situation would render that very difficult. Given that hibernate/3 messes with some core semantics (exception handling semantics) in Erlang, it should be used sparingly, and only as an optimisation in cases where reducing memory footprint is of the essence. Having said this, you can do what you ask without hacking gen.erl. Either "fake" a gen:call() message: {'$gen_call', {self(), Ref}, Request}, and wait for the reply, {Ref, Reply}. Not hard, but generally, one shouldn't cheat, or send a cast to the server and wait for an agreed reply. A basic gen_server-like call is really very simple: call(Server, Req) -> Ref = erlang:monitor(process, Server), Server ! {call, {self(), Ref}, Req}, receive {Ref, Reply} -> Reply; {'DOWN', Ref, _, _, Reason} -> error(Reason) end. BR, Ulf W Ulf Wiger, CTO, Erlang Solutions, Ltd. http://erlang-solutions.com From michael.eugene.turner@REDACTED Thu May 19 12:47:50 2011 From: michael.eugene.turner@REDACTED (Michael Turner) Date: Thu, 19 May 2011 19:47:50 +0900 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: <20110519093746.GB27904@erix.ericsson.se> References: <1930B4D4-54DD-4F80-ACDE-BBE983315E64@hates.ms> <20110519093746.GB27904@erix.ericsson.se> Message-ID: "But how interesting is whether existing code would break or not?" Not very. I mean, who uses Erlang for anything important? Hardly anybody, right? [/sarcasm] "It would, as others have pointed out, also be much harder to jump into a module and _know_ what the clause does since the function's name can be pages away." It would only be harder ("much"??) if you *chose*, in such cases, to use the syntax I propose to bring over from multi-clause funs. In the case you bring up, it might be wiser not to. And what I propose clearly allows everyone to continue with the present syntax. So your argument for readability in this case comes down to "somebody might not use this language feature wisely." (*facepalm*). -michael turner On Thu, May 19, 2011 at 6:37 PM, Raimo Niskanen < raimo+erlang-questions@REDACTED> wrote: > On Thu, May 19, 2011 at 01:50:33AM +0900, Michael Turner wrote: > > I'm still waiting for the answer to the real showstopper question: would > any > > existing code break, under my proposal? > > > > -michael turner > > > > I can not think of any existing code that would break, but there > are others that have weirder imagination than me. > > But how interesting is whether existing code would break or not? > > One nice thing with Erlang for me is that it is not like Perl; > there seldom seldom many ways to do it (syntacticly). > > The current compromise and limitation of having to write the > function name for every clause for regular function and not writing > any function name for funs I think is very good. It encourages > short funs and makes it easier to read long functions with > many clauses. If you restructure your code, move around clauses > often you run into a compilation error when you have messed up > clauses between functions. > > If you would remove the requirement of a function name on every > clause you would increase the possibility of getting completely > incorrect code through the compiler since it is enough that > the arity is the same between the clauses; you can accidentally > paste in a totally unrelated clause from some other function > and not discover it until it crashes in the field, provided > testing is incomplete (which it mostly is). > > It would, as others have pointed out, also be much harder to > jump into a module and _know_ what the clause does since > the function's name can be pages away. That would encourage > no more than page-long functions instead of no more than > page-long clauses and I sincerely prefere the latter. > > In short. I think the impact on readability and programmer's > common mistake preventions clearly does not motivate the change. > The possible benefits are minor. > > -- > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From watson.timothy@REDACTED Thu May 19 13:23:56 2011 From: watson.timothy@REDACTED (Tim Watson) Date: Thu, 19 May 2011 12:23:56 +0100 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: <1930B4D4-54DD-4F80-ACDE-BBE983315E64@hates.ms> <20110519093746.GB27904@erix.ericsson.se> Message-ID: >> It would, as others have pointed out, also be much harder to >> jump into a module and _know_ what the clause does since >> the function's name can be pages away. That would encourage >> no more than page-long functions instead of no more than >> page-long clauses and I sincerely prefere the latter. The current syntax for module level functions is perfectly reasonable today. Consider the Haskell equivalent, which is very similar: take1 _ [] = [] take1 0 _ = [] take1 n (x:xs) = x : take1 (n-1) xs In Ocaml you have some `match x with ...` noise to deal with, but it's much the same story. Personally I don't think there's anything wrong here. For funs though, having the parens but no name might be understandable but it is *ugly* to say the least. Perhaps the consistent approach would be to repeat the "fun" keyword, so an example might look like: process_glob(Proc) -> fun({Dir, #spec{path=Path, glob=undefined}=Spec}, {MapAcc, FoldAcc}) -> filter(Spec, [filename:join(Dir, Path)], MapAcc, FoldAcc); fun({Dir, #spec{glob=Glob}=Spec}, {MapAcc, FoldAcc}) -> filter(Spec, Proc(Dir, Glob), MapAcc, FoldAcc); fun({Dir, PathExpr}, {MapAcc, FoldAcc}) when is_list(PathExpr) -> filter(glob(PathExpr), Proc(Dir, PathExpr), MapAcc, FoldAcc) end. It's hardly elegant but at least it is consistent with the way "the other kind of function" is treated syntactically. Personally, I think a lot of the situations where working with funs is a pain, stem from the fact there's no easy way to do partial application. If the compiler team could give us that (maybe with a nice syntactic sugar for function composition on the side), I think it would be far more valuable than fiddling around with the syntax of anonymous functions. For the time being I'm using http://hg.rabbitmq.com/erlando and "cut", but it'd be nice to know how the language implementation is going to evolve in these kinds of areas. From fred.hebert@REDACTED Thu May 19 13:41:50 2011 From: fred.hebert@REDACTED (=?iso-8859-1?Q?Fr=E9d=E9ric_Trottier-H=E9bert?=) Date: Thu, 19 May 2011 07:41:50 -0400 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: <1930B4D4-54DD-4F80-ACDE-BBE983315E64@hates.ms> <20110519093746.GB27904@erix.ericsson.se> Message-ID: <7418517D-4A84-4F44-94E8-B15045F5DAC0@erlang-solutions.com> I would rather have one clear but slightly verbose way of doing things rather than two potential ways to do the same thing in slightly different manners prompting religious wars to get the same result I already have. The idea to revisit the syntax isn't bad in itself, but looking at the examples Steve Davis provided, I can only see your concept being useful for very short functions. When it comes to learning Erlang, I can tell you that in my experience, new users struggle a lot more with clause separators (;), expression separators (,), form terminators (.), records, 'if' or funs (in concept) than they do with function syntax. They do not seem to see the current way to write function heads as problematic. Then, all Erlang users are also used to it. Adding more ways to do things that currently have a single way to be done is a net loss in my opinion. People already complain that Erlang's syntax is too ugly or complex; I do not think that adding more syntax is the way to solve that. It would not benefit new users and it would not benefit the majority of all users, only increase the ways they can read code and get confused. In the other thread, someone called it 'syntactic salt', and I think this is a good way to describe how things are right now. It's not a bad thing in my opinion. On 2011-05-19, at 06:47 AM, Michael Turner wrote: > "But how interesting is whether existing code would break or not?" > > Not very. I mean, who uses Erlang for anything important? Hardly anybody, right? > > [/sarcasm] > > "It would, as others have pointed out, also be much harder to jump into a module and _know_ what the clause does since the function's name can be pages away." > > It would only be harder ("much"??) if you *chose*, in such cases, to use the syntax I propose to bring over from multi-clause funs. In the case you bring up, it might be wiser not to. And what I propose clearly allows everyone to continue with the present syntax. So your argument for readability in this case comes down to "somebody might not use this language feature wisely." (*facepalm*). > > -michael turner > _______ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Fred H?bert http://www.erlang-solutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimo+erlang-questions@REDACTED Thu May 19 13:56:02 2011 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Thu, 19 May 2011 13:56:02 +0200 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: <1930B4D4-54DD-4F80-ACDE-BBE983315E64@hates.ms> <20110519093746.GB27904@erix.ericsson.se> Message-ID: <20110519115601.GA1650@erix.ericsson.se> On Thu, May 19, 2011 at 07:47:50PM +0900, Michael Turner wrote: > "But how interesting is whether existing code would break or not?" Let me rephrase that: Whether existing code would break is only interesting if your change proposal is otherwise beneficial. [sarcasm] Could that also be misunderstood? [/sarcasm] > > Not very. I mean, who uses Erlang for anything important? Hardly anybody, > right? > > [/sarcasm] > > "It would, as others have pointed out, also be much harder to jump into a > module and _know_ what the clause does since the function's name can be > pages away." > > It would only be harder ("much"??) if you *chose*, in such cases, to use the > syntax I propose to bring over from multi-clause funs. In the case you bring > up, it might be wiser not to. And what I propose clearly allows everyone to > continue with the present syntax. So your argument for readability in this > case comes down to "somebody might not use this language feature wisely." > (*facepalm*). Exactly. If they only can use it wisely, where wisely sometimes - mostly in schoolbook toy examples, means having to redundantly repeat a function name, they can not use it unwisely. I regard that as positive. Syntactical freedom is not always productive over the whole lifetime of the code. Perl IMHO is an example of a language with too much freedom. > > -michael turner > -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From erlang@REDACTED Thu May 19 14:55:44 2011 From: erlang@REDACTED (Joe Armstrong) Date: Thu, 19 May 2011 14:55:44 +0200 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: Message-ID: On Thu, May 19, 2011 at 6:39 AM, Michael Turner < michael.eugene.turner@REDACTED> wrote: > Joe, with all due respect, I think you've misinterpreted DRY. It's not a > matter of writing something again because you can't find where it's already > implemented. In fact, the canonical example of DRY is to write something > that works for one case, and then, rather than define it as a function, > template or macro, and invoke it with varying parameters, instead > copy-paste-mutate for each case. In fact, the most common violations of DRY > are *precisely* when you know where the repeated code is, either because > you've just found it or because you've just written it. > > "DRY says that every piece of system knowledge should have one > authoritative, unambiguous representation." > > http://www.artima.com/intv/dry.html > > Erlang function definition syntax has two representations in the parser -- > for no good reason I can see. Why? > > "Changing syntax is *incredibly difficult* project managers get apoplectic > at the thought of retesting million lines of code -" > > No existing code will use the syntax I suggest. So how can any of it break? > > I have yet to get an answer: what could this proposed change possibly > break, even *theoretically*? > This is what happens. You change the language. Suppose this is supported in release R17 and thereafter. A while later new programmers use R17 and do not know that the new syntax was not supported in R12. The new programmer gets a job to fix a bug in some legacy code written using R12 they fix the code using the latest system (R17) and forget to test it on R12. When compiled with R14 the new code won't work - alternatively somebody writes a snazzy new library using R17 and the new features. Then somebody using R12 wants to include the new library. You might say - "tell them to upgrade to R17" and then they give you a load of really good reasons why they cannot do this. I'm not saying that this is a desirable state of affairs - I'm just describing what I see around me - the fault lies in the build system and the organizations ability to adept to change. project mangers say "it will cost me money and time to market" to change from R12 to R17 - but they might well want to use libraries developed in R17 in the R12 system - they can't if R17 uses things not understood in R12. It's worse than you think. An experienced programmer uses R17 and make a new library and publishes the library. A beginner (using R15) downloads the library tires to compile it - but the R15 compiler fails to compile the code and what is worse gives a completely incomprehensible warning that the program is wrong (because it doesn't understand *future* syntax) - the problem is that the beginner does not know that this is what has happened - it this point they can draw several false conclusions (Erlang is crap, the library is crap because it won't compile) Next problem - the beginner buy a couple of magnificent books describing Erlang - they then get *incredibly* confused to find that the syntax in published code using the new stuff is not described in the books anywhere - sign - "why did I buy this bloody book, grumble grumble ..." Erlang is sufficiently mature that the syntax is now very difficult to change. Yesterday evening I downloaded TWO different programs (not Erlang, but some other well-known and reasonably familiar language) - both claimed to run 'out of the box' - 'just type make' This is called *version nightmares* I'm sure they did work on the authors machine - but they didn't on mine. Make works if the right stuff is preinstalled. For Erlang I have a very precise idea of what is the latest dev. environment. But when I play with things written in python, or perl or ruby I get hit in the face all the time with this. Syntax was easy to change before we had thousands of users and millions of $ worth of software written in Erlang Erlang syntax has changed very infrequently and when it has changed it's been for a big benefit - I can think of a few examples, the introduction of (funs and list comprehensions) and the introduction of the bit syntax. Here the benefit far outweighs the cost. Small cosmetic changes to the language will not be made. If you want these make your own preprocessor and make sure it can cross compile into every past version of erlang and keep it updated for every future version. /Joe > > -michael turner > > On Thu, May 19, 2011 at 6:47 AM, Joe Armstrong wrote: > >> >> >> On Wed, May 18, 2011 at 5:29 PM, Parnell Springmeyer wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Sorry, but Erlang doesn't *need* a better chance of survival. This >>> language is not just growing, it's booming. Changing core language >>> features that are solid, well thought out, and non-harmful (in other >>> words, they are, FEATURES) to make it more "adoptable" is a lot like >>> someone saying, "you have to quit that quirky smile so other people will >>> like you more." >>> >> >> Languages survive forever once they get to the point where >> >> 1) legacy applications in the language still earn money >> 2) it costs more to convert to a new language than maintain the >> existing app in the old language >> >> Erlang reached this point, many years ago. >> >> Right now Erlang companies have a commercial advantage >> over non-erlang companies and so there is not much point in >> trying to spread the language further - you just loose your commercial >> advantage. >> >> /Joe >> >> >>> >>> Sometimes, yes, there are features in a language that could use >>> refinement - but many times, in a mature language, the ratio between >>> need and usefulness in refining a feature further, drops significantly. >>> >>> Instead of changing something that is solid, educate the people that >>> have a hard time grasping it, build killer example applications that >>> exhibit the quirky style and idioms to a T - people /will/ follow it, >>> almost to a religious end. >>> >>> That's actually what I like about Erlang the most, the documentation has >>> so many gems in it like the efficiency guide (where many common idioms >>> are expressed with clear DO and DON'T DO examples) and style guide. >>> >>> RE: syntactic consistency: Erlang's syntax *IS* consistent - it's more >>> consistent than many languages I've touched. >>> >>> Is Erlang easy for a Perl programmer? I bet not, and Perl's syntax is >>> less consistent than Erlang's is in my opinion. The issue you are >>> attempting to get at is (again) an educational and experience one, not >>> something that is inherently wrong with the language or its expression >>> itself. >>> >>> I'm actually baffled by the efforts people are putting into different >>> Erlang VM frontends that look like Ruby or Python. Good on them for >>> exercising the freedom of open source but /why/? Erlang's syntax is >>> almost beautiful to me now after using it, it's so well suited for what >>> Erlang is good at! >>> >>> Erlang isn't that great for general purpose programming - you use >>> Python, Ruby, C, D, etc... for stuff like that. Erlang is great at fault >>> tolerance, easy parallelism (which isn't easy!), and hot code >>> loading. Features that are so difficult to do in the traditional >>> imperative environment that (to date) I have not seen a single >>> implementation of any one of those features that even approaches the >>> completeness of Erlang's. >>> >>> Michael Turner writes: >>> >>> > Another objection raised against this syntax change is that all >>> > functional languages violate DRY in this manner, so it's OK if Erlang >>> > does it too. This is a Principle of Least Surprise argument, and not >>> > bad as far as it goes. But how far does it go? >>> > >>> > Erlang will have a better chance of greater success and survival if you >>> > consider your recruitment base to be the overwhelming majority of >>> > programmers. And from what I can tell, >>> > >>> > http://www.langpop.com >>> > >>> > the overwhelming majority of programmers have no experience to speak >>> > of, when it comes to functional programming languages. Appealing to the >>> > "cross-training" benefit of coming from other FP languages seems like a >>> > pretty weak argument. Especially since all I'm asking for here is >>> > syntactic consistency *within* Erlang -- a PLoS argument in itself. >>> > >>> > Richard O'Keefe suggests that the syntactic consistency goal is better >>> > met by allowing a kind of limited-scope special-case fun name, >>> > permitting, e.g. >>> > >>> > Fact = fun F(0) -> 1; F(N) -> N*F(N-1) end. >>> > >>> > I could get behind that too, but I don't follow his reasoning from >>> > syntactic consistency, which is apparently that an unnamed fun has a >>> > name, it's just the degenerate case of a name. It's really there. We >>> > just can't see it. Hm, really? If that were true in Erlang as it >>> > stands, shouldn't I be able to write it this way? >>> > >>> > Fact = fun (0) -> 1; (N) -> N*''(N-1) end. >>> > >>> > Looks like it's not quite that simple. It compiles, but it doesn't know >>> > what module to look in for '', when it comes time to execute. In the >>> > shell, I get an error indicating that it tried to resolve ''/1 as a >>> > shell command. Even if I put it in a .erl file and compile it, there's >>> > no obvious way to tell the compiler what module to look in. ?MODULE:'' >>> > doesn't work. Nor does '':'', which I tried just for the hell of it. >>> > >>> > What Richard's suggesting appears to require a rigorous re-think of how >>> > scopes are defined in Erlang. What I'm suggesting amounts to simply >>> > asking the compiler to do some of your tedious keying for you. >>> > >>> > -michael turner >>> > >>> > >>> > On Wed, May 18, 2011 at 6:16 PM, Michael Turner < >>> > michael.eugene.turner@REDACTED> wrote: >>> > >>> > I can say >>> > >>> > fun (1)->2; >>> > (2)->1 >>> > end >>> > >>> > but, oddly, I can't define a named function in the analogous way, >>> > e.g.: >>> > >>> > factorial >>> > (1) -> 1; >>> > (N) -> N*factorial(N-1). >>> > >>> > gives me a syntax error. I find the latter more readable than >>> > >>> > factorial(1) -> 1; >>> > factorial(2) -> N*fact(N-1). >>> > >>> > It's also less to type and to read, which is consistent with the >>> > DRY principle ("Don't Repeat Yourself"). And it lends itself to >>> > reading a function definition as a set of cases. I think for Erlang >>> > newbies, it should therefore would be preferred: it helps >>> > underscore the pattern-matching style of Erlang function >>> > invocation. >>> > >>> > It also looks a *little* bit more like the mathematical convention >>> > for defining these sorts of functions, where you have "f(x) = ", >>> > centered vertically to the left of a big left "{" that (left-) >>> > encloses the list of expression/parameter-condition pairs in a >>> > two-column format, e.g., >>> > >>> > http://cnx.org/content/m29517/latest/Picture%2047.png >>> > >>> > So there's a (weak) argument from the Principle of Least Surprise >>> > here as well. >>> > >>> > It seems to me that, if anything, this requires only a >>> > *simplification* of the Erlang parser. That leaves only one obvious >>> > objection: would any existing code break if Erlang syntax were >>> > altered to allow this? >>> > >>> > -michael turner >>> > >>> > _______________________________________________ >>> > erlang-questions mailing list >>> > erlang-questions@REDACTED >>> > http://erlang.org/mailman/listinfo/erlang-questions >>> >>> - -- >>> Parnell "ixmatus" Springmeyer (http://ixmat.us) >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG/MacGPG2 v2.0.17 (Darwin) >>> Comment: GPGTools - http://gpgtools.org >>> >>> iQEcBAEBAgAGBQJN0+XsAAoJEPvtlbpI1POLEXEIAJrjAGVTkveBi5/akYNMjBEX >>> 8wI9twatnXh8sfg2ohGKr3P1hj4jTr9ARrG5wiB9OCArRkBymnjFeY5g2dkBDOhN >>> aN722l+yDPpUewAM58m0dDoDHjrHXvxF1MJejQJGhQ+Nr9fM+7G+4QIrCN9RvX1S >>> QTAS+OqOnl8lsS98yvUiXXLB5ehdHcR46Ix6Sq7UwSvqaOKZMoPrzkTtW3VyS5kf >>> i/uGbPZ1I3KQJYRShk2QlLis/tpXGtLDnYc1E5uADqeClDXy5Au6LWpNqUjNIiWw >>> h8I2emcBq5Ur7nivNUYgnVMjg+0qTkQOtttPpOJ25xIYv07L+eMfXneb5nRx4hc= >>> =GGPU >>> -----END PGP SIGNATURE----- >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Thu May 19 14:58:01 2011 From: erlang@REDACTED (Joe Armstrong) Date: Thu, 19 May 2011 14:58:01 +0200 Subject: [erlang-questions] Understanding recursion Message-ID: I think how we teach recursion is wrong. Understanding recursion is really easy, all you have to do is understand recursion. /Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.james.barry@REDACTED Thu May 19 15:22:51 2011 From: paul.james.barry@REDACTED (Paul Barry) Date: Thu, 19 May 2011 14:22:51 +0100 Subject: [erlang-questions] Understanding recursion In-Reply-To: References: Message-ID: So... if I click on "Reply All", then this email message will itself recur, right? ;-) On 19 May 2011 13:58, Joe Armstrong wrote: > I think how we teach recursion is wrong. > > Understanding recursion is really easy, > all you have to do is understand recursion. > > /Joe > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- Paul Barry, w: http://paulbarry.itcarlow.ie, e: paul.barry@REDACTED Lecturer, Computer Networking: Institute of Technology, Carlow, Ireland. From the.malkolm@REDACTED Thu May 19 15:32:28 2011 From: the.malkolm@REDACTED (Alexander Krasnukhin) Date: Thu, 19 May 2011 15:32:28 +0200 Subject: [erlang-questions] Understanding recursion In-Reply-To: References: Message-ID: Just configure simplest auto answer in your mail client and write email to yourself. On Thu, May 19, 2011 at 3:22 PM, Paul Barry wrote: > So... if I click on "Reply All", then this email message will itself > recur, right? ;-) > > On 19 May 2011 13:58, Joe Armstrong wrote: > > I think how we teach recursion is wrong. > > > > Understanding recursion is really easy, > > all you have to do is understand recursion. > > > > /Joe > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > > -- > Paul Barry, w: http://paulbarry.itcarlow.ie, e: paul.barry@REDACTED > Lecturer, Computer Networking: Institute of Technology, Carlow, Ireland. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Regards, Alexander -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.eugene.turner@REDACTED Thu May 19 15:43:07 2011 From: michael.eugene.turner@REDACTED (Michael Turner) Date: Thu, 19 May 2011 22:43:07 +0900 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: Message-ID: Joe, a good deal of your argument from incompatibility falls down because the change I propose doesn't affect the binary (BEAM) code at all. The other parts of your argument relate to a problem shared with *every* language whose syntax has ever changed -- and that's all of them, except some dead ones perhaps. Should you try to be backward compatible with every release of every implementation of every language? Then languages wouldn't ever evolve. Is that such a good state of affairs? As for the befuddled newbie who runs smack into code not described in any book, supposedly becoming "*incredibly* confused ", that's pretty much a non-issue in this case the simple reason that, for its intended purpose, the syntax I propose is transparently obvious, at least if indented the way I propose (but that people here keep ignoring for some reason.) "Erlang is sufficiently mature that the syntax is now very difficult to change." Nobody has yet told me why this proposed change would break any existing code, or why it would require any significant work on the parser. But whatever: I'm only replying now because people keep misinterpreting me, or (from what I can tell) exaggerating the difficulties. It's not going to change? Well, OK. That's too bad. -michael turner On Thu, May 19, 2011 at 9:55 PM, Joe Armstrong wrote: > > > On Thu, May 19, 2011 at 6:39 AM, Michael Turner < > michael.eugene.turner@REDACTED> wrote: > >> Joe, with all due respect, I think you've misinterpreted DRY. It's not a >> matter of writing something again because you can't find where it's already >> implemented. In fact, the canonical example of DRY is to write something >> that works for one case, and then, rather than define it as a function, >> template or macro, and invoke it with varying parameters, instead >> copy-paste-mutate for each case. In fact, the most common violations of DRY >> are *precisely* when you know where the repeated code is, either because >> you've just found it or because you've just written it. >> >> "DRY says that every piece of system knowledge should have one >> authoritative, unambiguous representation." >> >> http://www.artima.com/intv/dry.html >> >> Erlang function definition syntax has two representations in the parser -- >> for no good reason I can see. Why? >> >> "Changing syntax is *incredibly difficult* project managers >> get apoplectic at the thought of retesting million lines of code -" >> >> No existing code will use the syntax I suggest. So how can any of it >> break? >> >> I have yet to get an answer: what could this proposed change possibly >> break, even *theoretically*? >> > > This is what happens. You change the language. Suppose this is supported in > release R17 and thereafter. > > A while later new programmers use R17 and do not know that the new syntax > was not supported in R12. > > The new programmer gets a job to fix a bug in some legacy code written > using R12 > they fix the code using the latest system (R17) and forget to test it on > R12. When compiled > with R14 the new code won't work - alternatively somebody writes a snazzy > new library using R17 > and the new features. Then somebody using R12 wants to include the new > library. > > You might say - "tell them to upgrade to R17" and then they give you a load > of really good reasons > why they cannot do this. > > I'm not saying that this is a desirable state of affairs - I'm just > describing what I see around me - the > fault lies in the build system and the organizations ability to adept to > change. > > project mangers say "it will cost me money and time to market" to change > from R12 to R17 - but they might > well want to use libraries developed in R17 in the R12 system - they can't > if R17 uses things not understood in R12. > > It's worse than you think. An experienced programmer uses R17 and make a > new library and > publishes the library. > > A beginner (using R15) downloads the library tires to compile it - but the > R15 compiler fails > to compile the code and what is worse gives a completely incomprehensible > warning that the program > is wrong (because it doesn't understand *future* syntax) - the problem is > that the beginner does not > know that this is what has happened - it this point they can draw several > false conclusions > (Erlang is crap, the library is crap because it won't compile) > > Next problem - the beginner buy a couple of magnificent books describing > Erlang - they > then get *incredibly* confused to find that the syntax in published code > using the new stuff > is not described in the books anywhere - sign - "why did I buy this bloody > book, grumble grumble ..." > > Erlang is sufficiently mature that the syntax is now very difficult to > change. > > Yesterday evening I downloaded TWO different programs (not Erlang, but some > other well-known > and reasonably familiar language) - both claimed to run 'out of the box' - > 'just type make' > > This is called *version nightmares* > > I'm sure they did work on the authors machine - but they didn't on mine. > Make works if the right stuff > is preinstalled. > > For Erlang I have a very precise idea of what is the latest dev. > environment. But when I play > with things written in python, or perl or ruby I get hit in the face all > the time with this. > > Syntax was easy to change before we had thousands of users and millions of > $ worth of software > written in Erlang > > Erlang syntax has changed very infrequently and when it has changed it's > been for a big benefit - > I can think of a few examples, the introduction of (funs and list > comprehensions) and the introduction > of the bit syntax. Here the benefit far outweighs the cost. > > Small cosmetic changes to the language will not be made. If you want these > make your own preprocessor > and make sure it can cross compile into every past version of erlang and > keep it updated for every future version. > > /Joe > > > >> >> -michael turner >> >> On Thu, May 19, 2011 at 6:47 AM, Joe Armstrong wrote: >> >>> >>> >>> On Wed, May 18, 2011 at 5:29 PM, Parnell Springmeyer wrote: >>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> Sorry, but Erlang doesn't *need* a better chance of survival. This >>>> language is not just growing, it's booming. Changing core language >>>> features that are solid, well thought out, and non-harmful (in other >>>> words, they are, FEATURES) to make it more "adoptable" is a lot like >>>> someone saying, "you have to quit that quirky smile so other people will >>>> like you more." >>>> >>> >>> Languages survive forever once they get to the point where >>> >>> 1) legacy applications in the language still earn money >>> 2) it costs more to convert to a new language than maintain the >>> existing app in the old language >>> >>> Erlang reached this point, many years ago. >>> >>> Right now Erlang companies have a commercial advantage >>> over non-erlang companies and so there is not much point in >>> trying to spread the language further - you just loose your commercial >>> advantage. >>> >>> /Joe >>> >>> >>>> >>>> Sometimes, yes, there are features in a language that could use >>>> refinement - but many times, in a mature language, the ratio between >>>> need and usefulness in refining a feature further, drops significantly. >>>> >>>> Instead of changing something that is solid, educate the people that >>>> have a hard time grasping it, build killer example applications that >>>> exhibit the quirky style and idioms to a T - people /will/ follow it, >>>> almost to a religious end. >>>> >>>> That's actually what I like about Erlang the most, the documentation has >>>> so many gems in it like the efficiency guide (where many common idioms >>>> are expressed with clear DO and DON'T DO examples) and style guide. >>>> >>>> RE: syntactic consistency: Erlang's syntax *IS* consistent - it's more >>>> consistent than many languages I've touched. >>>> >>>> Is Erlang easy for a Perl programmer? I bet not, and Perl's syntax is >>>> less consistent than Erlang's is in my opinion. The issue you are >>>> attempting to get at is (again) an educational and experience one, not >>>> something that is inherently wrong with the language or its expression >>>> itself. >>>> >>>> I'm actually baffled by the efforts people are putting into different >>>> Erlang VM frontends that look like Ruby or Python. Good on them for >>>> exercising the freedom of open source but /why/? Erlang's syntax is >>>> almost beautiful to me now after using it, it's so well suited for what >>>> Erlang is good at! >>>> >>>> Erlang isn't that great for general purpose programming - you use >>>> Python, Ruby, C, D, etc... for stuff like that. Erlang is great at fault >>>> tolerance, easy parallelism (which isn't easy!), and hot code >>>> loading. Features that are so difficult to do in the traditional >>>> imperative environment that (to date) I have not seen a single >>>> implementation of any one of those features that even approaches the >>>> completeness of Erlang's. >>>> >>>> Michael Turner writes: >>>> >>>> > Another objection raised against this syntax change is that all >>>> > functional languages violate DRY in this manner, so it's OK if Erlang >>>> > does it too. This is a Principle of Least Surprise argument, and not >>>> > bad as far as it goes. But how far does it go? >>>> > >>>> > Erlang will have a better chance of greater success and survival if >>>> you >>>> > consider your recruitment base to be the overwhelming majority of >>>> > programmers. And from what I can tell, >>>> > >>>> > http://www.langpop.com >>>> > >>>> > the overwhelming majority of programmers have no experience to speak >>>> > of, when it comes to functional programming languages. Appealing to >>>> the >>>> > "cross-training" benefit of coming from other FP languages seems like >>>> a >>>> > pretty weak argument. Especially since all I'm asking for here is >>>> > syntactic consistency *within* Erlang -- a PLoS argument in itself. >>>> > >>>> > Richard O'Keefe suggests that the syntactic consistency goal is better >>>> > met by allowing a kind of limited-scope special-case fun name, >>>> > permitting, e.g. >>>> > >>>> > Fact = fun F(0) -> 1; F(N) -> N*F(N-1) end. >>>> > >>>> > I could get behind that too, but I don't follow his reasoning from >>>> > syntactic consistency, which is apparently that an unnamed fun has a >>>> > name, it's just the degenerate case of a name. It's really there. We >>>> > just can't see it. Hm, really? If that were true in Erlang as it >>>> > stands, shouldn't I be able to write it this way? >>>> > >>>> > Fact = fun (0) -> 1; (N) -> N*''(N-1) end. >>>> > >>>> > Looks like it's not quite that simple. It compiles, but it doesn't >>>> know >>>> > what module to look in for '', when it comes time to execute. In the >>>> > shell, I get an error indicating that it tried to resolve ''/1 as a >>>> > shell command. Even if I put it in a .erl file and compile it, there's >>>> > no obvious way to tell the compiler what module to look in. ?MODULE:'' >>>> > doesn't work. Nor does '':'', which I tried just for the hell of it. >>>> > >>>> > What Richard's suggesting appears to require a rigorous re-think of >>>> how >>>> > scopes are defined in Erlang. What I'm suggesting amounts to simply >>>> > asking the compiler to do some of your tedious keying for you. >>>> > >>>> > -michael turner >>>> > >>>> > >>>> > On Wed, May 18, 2011 at 6:16 PM, Michael Turner < >>>> > michael.eugene.turner@REDACTED> wrote: >>>> > >>>> > I can say >>>> > >>>> > fun (1)->2; >>>> > (2)->1 >>>> > end >>>> > >>>> > but, oddly, I can't define a named function in the analogous way, >>>> > e.g.: >>>> > >>>> > factorial >>>> > (1) -> 1; >>>> > (N) -> N*factorial(N-1). >>>> > >>>> > gives me a syntax error. I find the latter more readable than >>>> > >>>> > factorial(1) -> 1; >>>> > factorial(2) -> N*fact(N-1). >>>> > >>>> > It's also less to type and to read, which is consistent with the >>>> > DRY principle ("Don't Repeat Yourself"). And it lends itself to >>>> > reading a function definition as a set of cases. I think for >>>> Erlang >>>> > newbies, it should therefore would be preferred: it helps >>>> > underscore the pattern-matching style of Erlang function >>>> > invocation. >>>> > >>>> > It also looks a *little* bit more like the mathematical convention >>>> > for defining these sorts of functions, where you have "f(x) = ", >>>> > centered vertically to the left of a big left "{" that (left-) >>>> > encloses the list of expression/parameter-condition pairs in a >>>> > two-column format, e.g., >>>> > >>>> > http://cnx.org/content/m29517/latest/Picture%2047.png >>>> > >>>> > So there's a (weak) argument from the Principle of Least Surprise >>>> > here as well. >>>> > >>>> > It seems to me that, if anything, this requires only a >>>> > *simplification* of the Erlang parser. That leaves only one >>>> obvious >>>> > objection: would any existing code break if Erlang syntax were >>>> > altered to allow this? >>>> > >>>> > -michael turner >>>> > >>>> > _______________________________________________ >>>> > erlang-questions mailing list >>>> > erlang-questions@REDACTED >>>> > http://erlang.org/mailman/listinfo/erlang-questions >>>> >>>> - -- >>>> Parnell "ixmatus" Springmeyer (http://ixmat.us) >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG/MacGPG2 v2.0.17 (Darwin) >>>> Comment: GPGTools - http://gpgtools.org >>>> >>>> iQEcBAEBAgAGBQJN0+XsAAoJEPvtlbpI1POLEXEIAJrjAGVTkveBi5/akYNMjBEX >>>> 8wI9twatnXh8sfg2ohGKr3P1hj4jTr9ARrG5wiB9OCArRkBymnjFeY5g2dkBDOhN >>>> aN722l+yDPpUewAM58m0dDoDHjrHXvxF1MJejQJGhQ+Nr9fM+7G+4QIrCN9RvX1S >>>> QTAS+OqOnl8lsS98yvUiXXLB5ehdHcR46Ix6Sq7UwSvqaOKZMoPrzkTtW3VyS5kf >>>> i/uGbPZ1I3KQJYRShk2QlLis/tpXGtLDnYc1E5uADqeClDXy5Au6LWpNqUjNIiWw >>>> h8I2emcBq5Ur7nivNUYgnVMjg+0qTkQOtttPpOJ25xIYv07L+eMfXneb5nRx4hc= >>>> =GGPU >>>> -----END PGP SIGNATURE----- >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fred.hebert@REDACTED Thu May 19 16:41:43 2011 From: fred.hebert@REDACTED (=?iso-8859-1?Q?Fr=E9d=E9ric_Trottier-H=E9bert?=) Date: Thu, 19 May 2011 10:41:43 -0400 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: Message-ID: <661C1ED1-0683-435C-8BF0-5EAB2289D546@erlang-solutions.com> Well let's take a look here. Syntax doesn't have to break old code to change, that's a good point. You'll see that if you try {lists, sort}([3,2,1]), you will obtain [1,2,3]. This basic fun syntax dates from before Erlang actually had funs (fun M:F/A). You'll notice that it was less complex, tends to avoid verbosity and is somewhat more readable than doing (fun lists:sort/1)([1,2,3]). Going to the new syntax didn't break any code, didn't require old working code to be rewritten (things still work the old way, and parametrized modules are based on that bit of syntax) and people just ignore it if they don't need it. Yet people did the switch from {Mod, Fun} to fun M:F/A. Why? Because, I figure, people generally liked the new way better: it's faster (apparently much faster), much cleaner in intent and purposes, and way easier to figure out that we're actually dealing with a higher order function and not some weird concept. Plus you have to consider that in many places, you can just use 'Var(Args)' with either form. This switch had many wins over conciseness. If we try to do the same with your suggestion for the new Erlang syntax, we can basically see that it has a few advantages: - reduces typing required by avoiding name repetitions - it doesn't break existing code - it somewhat unifies the syntax with funs, but then funs still finish with 'end' and take no name. I, however, see the following disadvantages: - it creates multiple standards left to personal preference - it makes it less obvious that a function has many clauses (see Steve Davis' code) - it creates more learning overhead if both forms are used. {Mod,Fun} for funs has no overhead because it's basically deprecated and nobody uses it. - All the existing tools have to be updated to understand it -- at least those working on source files (and this includes editors and whatnot) To this, you must add a multiplier damage (heh) for things it doesn't make better: - it's not faster (compile time, might even make compiling slower) - it doesn't make the parser code easier to maintain - it doesn't make maintaining code in modules easier (except for some readability benefits) - it's not helping people understand the language better (based on my observations that people have no problems with the current form when it comes to understanding) - it's making a lot of documentation obsolete that will need to be updated. This is common to all changes though. In my opinion, typing less code, even if it doesn't break compatibility, is not worth the change. You'll be creating a hell of a lot more work if only to get a bit more concise and consistent syntax on a thing where people don't even agree you get better readability. Oh and lastly, you could also have to consider this ambiguity -- is the following bit of code acceptable? my_function (a,b,c) -> {a,b,c}; (a,c,b) -> {a,b,v}; my_function (c,b,a) -> {a,b,c}. On 2011-05-19, at 09:43 AM, Michael Turner wrote: > "Erlang is sufficiently mature that the syntax is now very difficult to change." > > Nobody has yet told me why this proposed change would break any existing code, or why it would require any significant work on the parser. -- Fred H?bert http://www.erlang-solutions.com From pmacgown@REDACTED Thu May 19 16:47:58 2011 From: pmacgown@REDACTED (pmacgown@REDACTED) Date: Thu, 19 May 2011 14:47:58 +0000 (UTC) Subject: [erlang-questions] Understanding recursion In-Reply-To: Message-ID: <1007097077.498850.1305816478848.JavaMail.root@sz0166a.westchester.pa.mail.comcast.net> And using tail recursion, I don't have to have an infinite number of quoted quotes.? I just have to rewrite the original email and send it...only this time, it will be from Nairobi asking for banking account information because I have updated code on the fly. --Peter ----- Original Message ----- From: "Alexander Krasnukhin" To: "Paul Barry" Cc: "Erlang" Sent: Thursday, May 19, 2011 9:32:28 AM Subject: Re: [erlang-questions] Understanding recursion Just configure simplest auto answer in your mail client and write email to yourself. On Thu, May 19, 2011 at 3:22 PM, Paul Barry < paul.james.barry@REDACTED > wrote: So... if I click on "Reply All", then this email message will itself recur, right? ?;-) On 19 May 2011 13:58, Joe Armstrong < erlang@REDACTED > wrote: > I think how we teach recursion is wrong. > > Understanding recursion is really easy, > all you have to do is understand recursion. > > /Joe > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- Paul Barry, w: http://paulbarry.itcarlow.ie , e: paul.barry@REDACTED Lecturer, Computer Networking: Institute of Technology, Carlow, Ireland. _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -- Regards, Alexander _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From nox@REDACTED Thu May 19 17:05:23 2011 From: nox@REDACTED (Anthony Ramine) Date: Thu, 19 May 2011 17:05:23 +0200 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: <2b09c525-84a1-4723-80a6-19615241934b@h7g2000yqa.googlegroups.com> References: <2b09c525-84a1-4723-80a6-19615241934b@h7g2000yqa.googlegroups.com> Message-ID: A parse transform input must be a well-formed Erlang AST. You can't use that here. The parser will choke before it can parse transform the AST. Le 19 mai 2011 ? 01:12, Steve Davis a ?crit : > Since this is the second thread on this issue, I'm assuming you feel > very strongly about it. Why not file an EEP? > > Also you have the option to write a parse transform if you hate it > that much. > > My view remains "if it ain't broke don't fix it", since after a few > years of writing erlang programs, I do know that it ain't broke. > > My respectful 2c. > > /s > > On May 18, 9:18 am, Michael Turner > wrote: >> Another objection raised against this syntax change is that all functional >> languages violate DRY in this manner, so it's OK if Erlang does it too. This >> is a Principle of Least Surprise argument, and not bad as far as it goes. >> But how far does it go? >> >> Erlang will have a better chance of greater success and survival if you >> consider your recruitment base to be the overwhelming majority of >> programmers. And from what I can tell, >> >> http://www.langpop.com >> >> the overwhelming majority of programmers have no experience to speak of, >> when it comes to functional programming languages. Appealing to the >> "cross-training" benefit of coming from other FP languages seems like a >> pretty weak argument. Especially since all I'm asking for here is syntactic >> consistency *within* Erlang -- a PLoS argument in itself. >> >> Richard O'Keefe suggests that the syntactic consistency goal is better met >> by allowing a kind of limited-scope special-case fun name, permitting, e.g. >> >> Fact = fun F(0) -> 1; F(N) -> N*F(N-1) end. >> >> I could get behind that too, but I don't follow his reasoning from syntactic >> consistency, which is apparently that an unnamed fun has a name, it's just >> the degenerate case of a name. It's really there. We just can't see it. Hm, >> really? If that were true in Erlang as it stands, shouldn't I be able to >> write it this way? >> >> Fact = fun (0) -> 1; (N) -> N*''(N-1) end. >> >> Looks like it's not quite that simple. It compiles, but it doesn't know what >> module to look in for '', when it comes time to execute. In the shell, I get >> an error indicating that it tried to resolve ''/1 as a shell command. Even >> if I put it in a .erl file and compile it, there's no obvious way to tell >> the compiler what module to look in. ?MODULE:'' doesn't work. Nor does >> '':'', which I tried just for the hell of it. >> >> What Richard's suggesting appears to require a rigorous re-think of how >> scopes are defined in Erlang. What I'm suggesting amounts to simply asking >> the compiler to do some of your tedious keying for you. >> >> -michael turner >> >> On Wed, May 18, 2011 at 6:16 PM, Michael Turner < >> >> >> >> >> >> >> >> michael.eugene.tur...@REDACTED> wrote: >>> I can say >> >>> fun (1)->2; >>> (2)->1 >>> end >> >>> but, oddly, I can't define a named function in the analogous way, e.g.: >> >>> factorial >>> (1) -> 1; >>> (N) -> N*factorial(N-1). >> >>> gives me a syntax error. I find the latter more readable than >> >>> factorial(1) -> 1; >>> factorial(2) -> N*fact(N-1). >> >>> It's also less to type and to read, which is consistent with the DRY >>> principle ("Don't Repeat Yourself"). And it lends itself to reading a >>> function definition as a set of cases. I think for Erlang newbies, it should >>> therefore would be preferred: it helps underscore the pattern-matching style >>> of Erlang function invocation. >> >>> It also looks a *little* bit more like the mathematical convention for >>> defining these sorts of functions, where you have "f(x) = ", centered >>> vertically to the left of a big left "{" that (left-)encloses the list of >>> expression/parameter-condition pairs in a two-column format, e.g., >> >>> http://cnx.org/content/m29517/latest/Picture%2047.png >> >>> So there's a (weak) argument from the Principle of Least Surprise here as >>> well. >> >>> It seems to me that, if anything, this requires only a *simplification* of >>> the Erlang parser. That leaves only one obvious objection: would any >>> existing code break if Erlang syntax were altered to allow this? >> >>> -michael turner >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Anthony Ramine Dev:Extend http://dev-extend.eu From jws@REDACTED Thu May 19 17:15:36 2011 From: jws@REDACTED (Jeff Schultz) Date: Fri, 20 May 2011 01:15:36 +1000 Subject: [erlang-questions] 'reply-to' header in this mailing list In-Reply-To: <600128661.198501305727597470.JavaMail.root@zimbra> References: <688144131.198481305727593991.JavaMail.root@zimbra> <600128661.198501305727597470.JavaMail.root@zimbra> Message-ID: <20110519151536.GA11239@mulga.csse.unimelb.edu.au> On Wed, May 18, 2011 at 02:06:37PM +0000, Robert Virding wrote: > How about we completely side-step the whole issue and re-structure > the various erlang mailing lists a forum instead? And by choosing one > of the common and free forum packages we will automatically get a > standard (in the sense of being common and much used) behaviour. > This is also a serious suggestion. -1. The mailing list works well the way it is. (As far as my, personal, workflow is concerned, forum software makes it hard work for me to collect the material I will want to look at again and catalogue it to suit my needs. I suppose businesses like Google prefer that because they can serve me new ads each time I look for something I remember seeing last year that might be helpful to me right now. I see that as their problem, not mine.) Jeff Schultz From mrtndimitrov@REDACTED Thu May 19 17:36:02 2011 From: mrtndimitrov@REDACTED (Martin Dimitrov) Date: Thu, 19 May 2011 18:36:02 +0300 Subject: [erlang-questions] call by value Message-ID: <4DD538E2.70107@gmail.com> Hi, How will we have to interpret this citation from "Erlang Programming" by Francesco Cesarini and Simon Thompson (page 30): "All calls with variables in Erlang are call by value: all arguments to a function call are evaluated before the body of the function is evaluated. The concept of call by reference does not exist, ..." I know that variables are not copied when making a function call and are copied when sending messages to processes. So why do the authors say all calls are call by value? Aren't the function calls actually call by reference? Regards, Martin From matthew@REDACTED Thu May 19 17:40:40 2011 From: matthew@REDACTED (Matthew Sackman) Date: Thu, 19 May 2011 16:40:40 +0100 Subject: [erlang-questions] call by value In-Reply-To: <4DD538E2.70107@gmail.com> References: <4DD538E2.70107@gmail.com> Message-ID: <20110519154040.GD23647@rabbitmq.com> On Thu, May 19, 2011 at 06:36:02PM +0300, Martin Dimitrov wrote: > I know that variables are not copied when making a function call and are > copied when sending messages to processes. So why do the authors say all > calls are call by value? Aren't the function calls actually call by > reference? Well I think there is a difference of interpretation of the terminology based on whether you're in C world or functional world. To me, they're more talking about laziness: Erlang is strict and as such expressions in arguments to function calls are reduced to terms before the function is invoked. I'm not sure that's exactly the same as call by value, but given the idempotency of data structures in functional languages generally, it's not clear that a C-style interpretation of call-by-value or call-by-reference has any meaning for functional languages. Matthew From ulf.wiger@REDACTED Thu May 19 17:41:23 2011 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Thu, 19 May 2011 17:41:23 +0200 Subject: [erlang-questions] call by value In-Reply-To: <4DD538E2.70107@gmail.com> References: <4DD538E2.70107@gmail.com> Message-ID: <52EA5205-148D-46F8-AA22-C96059C14F56@erlang-solutions.com> You should ignore the issue of copying. Essentially, Erlang can be viewed as using copy-on-write semantics. The key is whether the expression is evaluated or not (it is) before the function is called, and also whether the called function can modify the input parameters (it can't)*. * Unless you use unholy functions like hipe_bifs:bytearray_update/3, which of course you don't. ;-) BR, Ulf W On 19 May 2011, at 17:36, Martin Dimitrov wrote: > Hi, > > How will we have to interpret this citation from "Erlang Programming" by > Francesco Cesarini and Simon Thompson (page 30): > > "All calls with variables in Erlang are call by value: all arguments to > a function call are evaluated before the body of the function is > evaluated. The concept of call by reference does not exist, ..." > > I know that variables are not copied when making a function call and are > copied when sending messages to processes. So why do the authors say all > calls are call by value? Aren't the function calls actually call by > reference? > > Regards, > > Martin > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions Ulf Wiger, CTO, Erlang Solutions, Ltd. http://erlang-solutions.com From dan@REDACTED Thu May 19 17:43:58 2011 From: dan@REDACTED (Daniel Dormont) Date: Thu, 19 May 2011 11:43:58 -0400 Subject: [erlang-questions] call by value In-Reply-To: <4DD538E2.70107@gmail.com> References: <4DD538E2.70107@gmail.com> Message-ID: In my experience with other languages, the difference between call-by-value and call-by-reference is not generally understood to depend on whether the data in memory is physically copied or not. That's really an implementation detail. Rather, the difference is whether the argument "itself" is passed as opposed to its value. Personally, I consider the distinction meaningless in languages like Erlang (or Haskell, or even, say, SQL) that lack mutable variables. dan On May 19, 2011, at 11:36 AM, Martin Dimitrov wrote: > Hi, > > How will we have to interpret this citation from "Erlang Programming" by > Francesco Cesarini and Simon Thompson (page 30): > > "All calls with variables in Erlang are call by value: all arguments to > a function call are evaluated before the body of the function is > evaluated. The concept of call by reference does not exist, ..." > > I know that variables are not copied when making a function call and are > copied when sending messages to processes. So why do the authors say all > calls are call by value? Aren't the function calls actually call by > reference? > > Regards, > > Martin > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From mrtndimitrov@REDACTED Thu May 19 17:50:17 2011 From: mrtndimitrov@REDACTED (Martin Dimitrov) Date: Thu, 19 May 2011 18:50:17 +0300 Subject: [erlang-questions] call by value In-Reply-To: References: <4DD538E2.70107@gmail.com> Message-ID: <4DD53C39.6060605@gmail.com> On 5/19/2011 6:43 PM, Daniel Dormont wrote: > In my experience with other languages, the difference between call-by-value and call-by-reference is not generally understood to depend on whether the data in memory is physically copied or not. That's really an implementation detail. On first read I can't think of an example where the implementation is not actually copying the value. > Rather, the difference is whether the argument "itself" is passed as opposed to its value. > Would then in Erlang be more appropriate to say that the argument "itself" is being passed, thus saying call-by-reference? From psa@REDACTED Thu May 19 17:59:20 2011 From: psa@REDACTED (=?ISO-8859-1?Q?Paulo_S=E9rgio_Almeida?=) Date: Thu, 19 May 2011 16:59:20 +0100 Subject: [erlang-questions] call by value In-Reply-To: <52EA5205-148D-46F8-AA22-C96059C14F56@erlang-solutions.com> References: <4DD538E2.70107@gmail.com> <52EA5205-148D-46F8-AA22-C96059C14F56@erlang-solutions.com> Message-ID: <4DD53E58.4050909@di.uminho.pt> On 5/19/11 4:41 PM, Ulf Wiger wrote: > You should ignore the issue of copying. Essentially, Erlang can be viewed as using copy-on-write semantics. > > The key is whether the expression is evaluated or not (it is) before the function is called, and also whether the called function can modify the input parameters (it can't)*. > > * Unless you use unholy functions like hipe_bifs:bytearray_update/3, which of course you don't. ;-) Unless you need to implement huge bloom filters with good performance. ;-) Regards, Paulo > BR, > Ulf W > > On 19 May 2011, at 17:36, Martin Dimitrov wrote: > >> Hi, >> >> How will we have to interpret this citation from "Erlang Programming" by >> Francesco Cesarini and Simon Thompson (page 30): >> >> "All calls with variables in Erlang are call by value: all arguments to >> a function call are evaluated before the body of the function is >> evaluated. The concept of call by reference does not exist, ..." >> >> I know that variables are not copied when making a function call and are >> copied when sending messages to processes. So why do the authors say all >> calls are call by value? Aren't the function calls actually call by >> reference? >> >> Regards, >> >> Martin >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > Ulf Wiger, CTO, Erlang Solutions, Ltd. > http://erlang-solutions.com > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From rtrlists@REDACTED Thu May 19 18:14:49 2011 From: rtrlists@REDACTED (Robert Raschke) Date: Thu, 19 May 2011 17:14:49 +0100 Subject: [erlang-questions] call by value In-Reply-To: <4DD53C39.6060605@gmail.com> References: <4DD538E2.70107@gmail.com> <4DD53C39.6060605@gmail.com> Message-ID: On Thu, May 19, 2011 at 4:50 PM, Martin Dimitrov wrote: > On 5/19/2011 6:43 PM, Daniel Dormont wrote: > > In my experience with other languages, the difference between > call-by-value and call-by-reference is not generally understood to depend on > whether the data in memory is physically copied or not. That's really an > implementation detail. > On first read I can't think of an example where the implementation is > not actually copying the value. > > Rather, the difference is whether the argument "itself" is passed as > opposed to its value. > > > Would then in Erlang be more appropriate to say that the argument > "itself" is being passed, thus saying call-by-reference? > > You have to remember that in Erlang there are only values. You don't have references. What you have is names for values, but that's all it is, a name for a value, just like you use the word "one" to denote the value of the numeral 1. The great thing about having only values, is that you don't have to make copies in memory, because there's no way to destroy or update them. You can emulate references by using state carrying data structures. Some assembly required. Robby PS And yes, you can delve into deeper aspects, where the "value" metaphor breaks down a bit. But usually you need to have a reasonably good reason for doing that. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew@REDACTED Thu May 19 18:17:21 2011 From: matthew@REDACTED (Matthew Sackman) Date: Thu, 19 May 2011 17:17:21 +0100 Subject: [erlang-questions] call by value In-Reply-To: References: <4DD538E2.70107@gmail.com> <4DD53C39.6060605@gmail.com> Message-ID: <20110519161721.GE23647@rabbitmq.com> On Thu, May 19, 2011 at 05:14:49PM +0100, Robert Raschke wrote: > You have to remember that in Erlang there are only values. You don't have > references. What you have is names for values, but that's all it is, a name > for a value, just like you use the word "one" to denote the value of the > numeral 1. Though interestingly, you can think of a Pid as a reference to a process. Likewise Refs (clue is in the name ;)) and Ports. Matthew From ulf.wiger@REDACTED Thu May 19 18:17:29 2011 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Thu, 19 May 2011 18:17:29 +0200 Subject: [erlang-questions] call by value In-Reply-To: <4DD53E58.4050909@di.uminho.pt> References: <4DD538E2.70107@gmail.com> <52EA5205-148D-46F8-AA22-C96059C14F56@erlang-solutions.com> <4DD53E58.4050909@di.uminho.pt> Message-ID: <8580F713-24DC-4DC9-930E-716ABE37296C@erlang-solutions.com> On 19 May 2011, at 17:59, Paulo S?rgio Almeida wrote: > On 5/19/11 4:41 PM, Ulf Wiger wrote: >> You should ignore the issue of copying. Essentially, Erlang can be viewed as using copy-on-write semantics. >> >> The key is whether the expression is evaluated or not (it is) before the function is called, and also whether the called function can modify the input parameters (it can't)*. >> >> * Unless you use unholy functions like hipe_bifs:bytearray_update/3, which of course you don't. ;-) > Unless you need to implement huge bloom filters with good performance. ;-) Yeah, well, I was bitten by exactly that last week, as I prepared a code kata based on a bloom filter. I had a bloom filter implementation that used hipe_bifs:bitarray_update/3 for performance and simplicity, but since I was messing with those, I used them also in the code calling on the bloom filter (which was to find all words of a given length). The fun started when I then made a QLC generator out of the CPS-style word finder. It worked, but instead of returning all words of length N, it returned a list of several instances of the SAME word. It took me a little while to realise that, as I was using destructive update when permuting the "character vector", the QLC iterator kept mutating the same binary the whole time, and simply returned a pointer to that one binary for each word found. Mutation is evil? BR, Ulf W Ulf Wiger, CTO, Erlang Solutions, Ltd. http://erlang-solutions.com From jesper.louis.andersen@REDACTED Thu May 19 18:23:27 2011 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Thu, 19 May 2011 18:23:27 +0200 Subject: [erlang-questions] call by value In-Reply-To: <4DD538E2.70107@gmail.com> References: <4DD538E2.70107@gmail.com> Message-ID: On Thu, May 19, 2011 at 17:36, Martin Dimitrov wrote: > "All calls with variables in Erlang are call by value: all arguments to > a function call are evaluated before the body of the function is > evaluated. The concept of call by reference does not exist, ..." I'll reply even though others have replied and add a bit more flesh. Suppose we have a function: f(X) -> X + 7. and we want to call it like this: f(3 + 5), now there are two ways the reduction can proceed. Either we first evaluate the expression and then make the call, f(3 + 5) ==> f(8) ==> 8 + 7 ==> 15 which is the call-by-value evaluation strategy, or we do it by substituting in the expression first, f(3 + 5) ==> (3 + 5) + 7 ==> 8 + 7 ==> 15 which is the call-by-reference evaluation strategy. Erlang is a Call-by-value (or an eager/strict) language. Clean and Haskell are good examples of languages that use a variant the call-by-reference strategy named call-by-need. You may be confusing the evaluation strategy with whether parameters are passed by value or by reference. This is an important notion in an imperative language like Java, C, C++, Go, etc, but in functional languages pass-by-value is the only thing you can do. Remember though that in a functional language values are persistent and thus immutable. Hence, we can get away with reusing the same in-memory structure over and over again until we change it. And when we do change it, we can exploit to share as much as possible from the old structure. We define L = [1], with an in-memory representation like this: {P1} ==> [] where P1 is a pointer to a cell containing the value 1 and ===> is a pointer and [] is a special value signifying the end-of-list. Now, if cons it two times: L2 = [2 | L], L3 = [3 | L], We get two lists like this: {P2} ====\ {P1} ==> [] {P3} ====/ My ASCII-art hopefully showing how the L2 and L3 lists share the tail. Immutability like this means we can just pass a reference and that is as good as having made a copy of the whole data structure. It can be exploited by your programs giving you some possibilities which are quite funny to think about. For instance: X = 3, L = {X, X} L2 = {L, L}, L3 = {L2, L2}, L4 = {L3, L3}, L5 = {L4, L4}. L5 is built in linear time and contains 32 X cells. That is, we just built an exponentially large data structure in linear time. Also, all of it references the same X in memory. Yet if we ask for the sum of the tree-like structure, then we would get the correct answer of 32 * 3. So in conclusion: everything is passed by value, but where possible, Erlang will pass by reference due to the immutable behaviour of the Erlang heap. So the whole question of the passing style (value/refence) is specific the implementation and not needed to understand how the language evaluates (everything is pass-by-value). > I know that variables are not copied when making a function call and are > copied when sending messages to processes. So why do the authors say all > calls are call by value? Aren't the function calls actually call by > reference? Yes, when you send a message to another process, Erlang has to move the structure you are sending to the other process. This is because processes have separate heaps, so you must somehow move the data from one heap to the other and copying is the quickest/simplest way to do that. Storing and retrieving data from/to ETS has the same copying. -- J. From jesper.louis.andersen@REDACTED Thu May 19 18:28:27 2011 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Thu, 19 May 2011 18:28:27 +0200 Subject: [erlang-questions] call by value In-Reply-To: References: <4DD538E2.70107@gmail.com> Message-ID: On Thu, May 19, 2011 at 18:23, Jesper Louis Andersen wrote: > > f(3 + 5) ==> (3 + 5) + 7 ==> 8 + 7 ==> 15 > > which is the call-by-reference evaluation strategy. Erlang is a > Call-by-value (or an eager/strict) language. Clean and Haskell are > good examples of languages that use a variant the call-by-reference > strategy named call-by-need. > Ok, I was wrong here. Haskell and Clean are call-by-need, but I was thinking of call-by-name and not call by reference. My bad, see http://en.wikipedia.org/wiki/Evaluation_strategy for the full information about it. -- J. From dmercer@REDACTED Thu May 19 18:35:14 2011 From: dmercer@REDACTED (David Mercer) Date: Thu, 19 May 2011 11:35:14 -0500 Subject: [erlang-questions] 'reply-to' header in this mailing list In-Reply-To: <600128661.198501305727597470.JavaMail.root@zimbra> References: <688144131.198481305727593991.JavaMail.root@zimbra> <600128661.198501305727597470.JavaMail.root@zimbra> Message-ID: <016d01cc1642$bc4dce10$34e96a30$@com> My comments in-line with reply below. From: erlang-questions-bounces@REDACTED [mailto:erlang-questions-bounces@REDACTED] On Behalf Of Robert Virding Sent: Wednesday, May 18, 2011 9:07 AM To: Alexander Krasnukhin Cc: erlang-questions@REDACTED Subject: Re: [erlang-questions] 'reply-to' header in this mailing list How about we completely side-step the whole issue and re-structure the various erlang mailing lists a forum instead? And by choosing one of the common and free forum packages we will automatically get a standard (in the sense of being common and much used) behaviour. This is also a serious suggestion. [DBM] What?s the difference between a forum and a mailing list? I tend to think of forums as being something like Usenet, but I haven?t used that in years. Some people seem to think they?re like Google Groups, which I don?t really use that much. Can someone please elucidate the distinction between a mailing list and a forum? Thanks. DBM -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmercer@REDACTED Thu May 19 18:35:14 2011 From: dmercer@REDACTED (David Mercer) Date: Thu, 19 May 2011 11:35:14 -0500 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: <4DD4D961.5000703@gmail.com> References: <2b09c525-84a1-4723-80a6-19615241934b@h7g2000yqa.googlegroups.com> <4DD4D59A.6080708@gmail.com> <4DD4D961.5000703@gmail.com> Message-ID: <017201cc1642$bd5b4670$3811d350$@com> On Thursday, May 19, 2011, Steve Davis wrote: > Out of interest, I tried it on one of my own modules. > > Your way: https://gist.github.com/980420 > The highway: > https://github.com/komone/qrcode/blob/master/src/base32.erl > > In order to make your way less confusing, as the pattern matching entry > points to the function were extremely un-obvious, and in the spirit of > making it work I tried "double indent". > Double indented: https://gist.github.com/980412 > > For me, either way, the intention is harder to read, and/or forces me > to > focus on/put in a bunch of white space. > > What do you think? I've got to admit: I prefer the double-indented version, especially with the syntax coloring. I'd probably put a newline between the function name and the arguments of the first clause, but it did seem to make it more clear to me which were clauses of the same function and which were a different one. But, that being said, I still stand by my statement from the previous thread that repeating the function name is syntactic salt that helps prevent some errors. As Raimo well put it later on in the thread: > If you would remove the requirement of a function name on every > clause you would increase the possibility of getting completely > incorrect code through the compiler since it is enough that > the arity is the same between the clauses; you can accidentally > paste in a totally unrelated clause from some other function > and not discover it until it crashes in the field, provided > testing is incomplete (which it mostly is). Therefore, I do not think we need to accommodate the DRYer syntax. Cheers, y'all! DBM From dennis.duong.646@REDACTED Thu May 19 18:35:52 2011 From: dennis.duong.646@REDACTED (ag3nt911) Date: Thu, 19 May 2011 09:35:52 -0700 (PDT) Subject: [erlang-questions] gen_server:call and hibernate In-Reply-To: <271ABE52-4C73-4FB5-B35F-BC25BBAE8413@erlang-solutions.com> References: <1305763507064-3534336.post@n4.nabble.com> <271ABE52-4C73-4FB5-B35F-BC25BBAE8413@erlang-solutions.com> Message-ID: <1305822952558-3536301.post@n4.nabble.com> Ulf, Thanks! indeed, the gen_server:call is quite simple. I should have traced it and saw it for myself. Initially i thought a gen_server:cast would make more sense to use but what I couldn't grasp is why facebook developers would prefer gen_server:call over gen_server;cast instead. Is there any catch to using a method where: TimerRef = erlang:start_timer(60000, self(), {timedout, Data}), %% gen_server:call(ServerPid, {message, SomeData}), Ref = erlang:monitor(process, ServerPid), ServerPid ! {call, {self(), Ref}, SomeData}, proc_lib:hibernate(?MODULE, func, [TimerRef]). as opposed to: TimerRef = erlang:start_timer(60000, self(), {timedout, Data}), gen_server:cast(ServerPid, {message, SomeData}), proc_lib:hibernate(?MODULE, func, [TimerRef]). -- View this message in context: http://erlang.2086793.n4.nabble.com/gen-server-call-and-hibernate-tp3534336p3536301.html Sent from the Erlang Questions mailing list archive at Nabble.com. From dennis.duong.646@REDACTED Thu May 19 18:36:46 2011 From: dennis.duong.646@REDACTED (ag3nt911) Date: Thu, 19 May 2011 09:36:46 -0700 (PDT) Subject: [erlang-questions] gen_server:call and hibernate In-Reply-To: References: <1305763507064-3534336.post@n4.nabble.com> Message-ID: <1305823006371-3536303.post@n4.nabble.com> Tim, Thanks for the info! The file looks very neat and readable. I'll just have to poke around after work today :) -- View this message in context: http://erlang.2086793.n4.nabble.com/gen-server-call-and-hibernate-tp3534336p3536303.html Sent from the Erlang Questions mailing list archive at Nabble.com. From ulf.wiger@REDACTED Thu May 19 18:47:28 2011 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Thu, 19 May 2011 18:47:28 +0200 Subject: [erlang-questions] gen_server:call and hibernate In-Reply-To: <1305822952558-3536301.post@n4.nabble.com> References: <1305763507064-3534336.post@n4.nabble.com> <271ABE52-4C73-4FB5-B35F-BC25BBAE8413@erlang-solutions.com> <1305822952558-3536301.post@n4.nabble.com> Message-ID: The subtle difference is that a gen_server:cast assumes a gen_server on the receiving end, and the request ends up in handle_cast/2. A plain message ends up in handle_info/2. At least I tend to prefer cast for messages that are part of the internal protocol, leaving handle_info/2 for messages where I don't control the sending side. BR, Ulf W On 19 May 2011, at 18:35, ag3nt911 wrote: > Ulf, > > Thanks! indeed, the gen_server:call is quite simple. I should have traced it > and saw it for myself. Initially i thought a gen_server:cast would make more > sense to use but what I couldn't grasp is why facebook developers would > prefer gen_server:call over gen_server;cast instead. Is there any catch to > using a method where: > > TimerRef = erlang:start_timer(60000, self(), {timedout, Data}), > %% gen_server:call(ServerPid, {message, SomeData}), > Ref = erlang:monitor(process, ServerPid), > ServerPid ! {call, {self(), Ref}, SomeData}, > proc_lib:hibernate(?MODULE, func, [TimerRef]). > > as opposed to: > > TimerRef = erlang:start_timer(60000, self(), {timedout, Data}), > gen_server:cast(ServerPid, {message, SomeData}), > proc_lib:hibernate(?MODULE, func, [TimerRef]). > > > > -- > View this message in context: http://erlang.2086793.n4.nabble.com/gen-server-call-and-hibernate-tp3534336p3536301.html > Sent from the Erlang Questions mailing list archive at Nabble.com. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions Ulf Wiger, CTO, Erlang Solutions, Ltd. http://erlang-solutions.com From vances@REDACTED Thu May 19 18:57:16 2011 From: vances@REDACTED (Vance Shipley) Date: Thu, 19 May 2011 22:27:16 +0530 Subject: [erlang-questions] 'reply-to' header in this mailing list In-Reply-To: <016d01cc1642$bc4dce10$34e96a30$@com> References: <688144131.198481305727593991.JavaMail.root@zimbra> <600128661.198501305727597470.JavaMail.root@zimbra> <016d01cc1642$bc4dce10$34e96a30$@com> Message-ID: <20110519165711.GQ7320@aluminum.local> On Thu, May 19, 2011 at 11:35:14AM -0500, David Mercer wrote: } Can someone please elucidate the distinction between a mailing } list and a forum? I have come to the conclusion that what is beneath these sort of debates amounts to a generational gap. Those who grew up with a mouse in their hands have different expectations than those of us who grew up with our hands planted on the keyboard looking at a command prompt. As one of the later my view is that the distinction is: mailing list: push forum: pull -- -Vance From moxford@REDACTED Thu May 19 19:19:11 2011 From: moxford@REDACTED (Mike Oxford) Date: Thu, 19 May 2011 10:19:11 -0700 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: Message-ID: Noting that I'm not against core language changes where critically warranted, why is this one particular thing such an issue to you? Erlang is not an ivory-tower-on-a-hill-university-project. It's an organically-grown beast that gets down in the trenches and brawls in the mud. If you don't like it, write it off as an "Erlang wart." Every language has them. If you don't like it then write your own, or your own parser. For what it's worth, some users (such as myself) actually PREFER it the way it is because it makes code-scanning easier from a visual standpoint. Yes, I'm one of those people who will put "comment breaks" between methods in my code, too, regardless of language. And to reference your copy-paste-mutate argument....what do you think we'll be doing for every internal case-clause? Yes, that's right, copy-paste-mutate the pattern matches except that you now have your logical branches at indent-level-1 with, potentially, the rest of your code that doesn't deal with argument-specific code instead of at indent-level-0. If you need "common chunks of code" well, I'm pretty sure that's why we have methods. To wit, write your "unified interface" and case it yourself and call the argument specific sub-method. My vote: keep it as it is. -mox On Wed, May 18, 2011 at 9:39 PM, Michael Turner < michael.eugene.turner@REDACTED> wrote: > Joe, with all due respect, I think you've misinterpreted DRY. It's not a > matter of writing something again because you can't find where it's already > implemented. In fact, the canonical example of DRY is to write something > that works for one case, and then, rather than define it as a function, > template or macro, and invoke it with varying parameters, instead > copy-paste-mutate for each case. In fact, the most common violations of DRY > are *precisely* when you know where the repeated code is, either because > you've just found it or because you've just written it. > > "DRY says that every piece of system knowledge should have one > authoritative, unambiguous representation." > > http://www.artima.com/intv/dry.html > > Erlang function definition syntax has two representations in the parser -- > for no good reason I can see. Why? > > "Changing syntax is *incredibly difficult* project managers get apoplectic > at the thought of retesting million lines of code -" > > No existing code will use the syntax I suggest. So how can any of it break? > > I have yet to get an answer: what could this proposed change possibly > break, even *theoretically*? > > -michael turner > > On Thu, May 19, 2011 at 6:47 AM, Joe Armstrong wrote: > >> >> >> On Wed, May 18, 2011 at 5:29 PM, Parnell Springmeyer wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Sorry, but Erlang doesn't *need* a better chance of survival. This >>> language is not just growing, it's booming. Changing core language >>> features that are solid, well thought out, and non-harmful (in other >>> words, they are, FEATURES) to make it more "adoptable" is a lot like >>> someone saying, "you have to quit that quirky smile so other people will >>> like you more." >>> >> >> Languages survive forever once they get to the point where >> >> 1) legacy applications in the language still earn money >> 2) it costs more to convert to a new language than maintain the >> existing app in the old language >> >> Erlang reached this point, many years ago. >> >> Right now Erlang companies have a commercial advantage >> over non-erlang companies and so there is not much point in >> trying to spread the language further - you just loose your commercial >> advantage. >> >> /Joe >> >> >>> >>> Sometimes, yes, there are features in a language that could use >>> refinement - but many times, in a mature language, the ratio between >>> need and usefulness in refining a feature further, drops significantly. >>> >>> Instead of changing something that is solid, educate the people that >>> have a hard time grasping it, build killer example applications that >>> exhibit the quirky style and idioms to a T - people /will/ follow it, >>> almost to a religious end. >>> >>> That's actually what I like about Erlang the most, the documentation has >>> so many gems in it like the efficiency guide (where many common idioms >>> are expressed with clear DO and DON'T DO examples) and style guide. >>> >>> RE: syntactic consistency: Erlang's syntax *IS* consistent - it's more >>> consistent than many languages I've touched. >>> >>> Is Erlang easy for a Perl programmer? I bet not, and Perl's syntax is >>> less consistent than Erlang's is in my opinion. The issue you are >>> attempting to get at is (again) an educational and experience one, not >>> something that is inherently wrong with the language or its expression >>> itself. >>> >>> I'm actually baffled by the efforts people are putting into different >>> Erlang VM frontends that look like Ruby or Python. Good on them for >>> exercising the freedom of open source but /why/? Erlang's syntax is >>> almost beautiful to me now after using it, it's so well suited for what >>> Erlang is good at! >>> >>> Erlang isn't that great for general purpose programming - you use >>> Python, Ruby, C, D, etc... for stuff like that. Erlang is great at fault >>> tolerance, easy parallelism (which isn't easy!), and hot code >>> loading. Features that are so difficult to do in the traditional >>> imperative environment that (to date) I have not seen a single >>> implementation of any one of those features that even approaches the >>> completeness of Erlang's. >>> >>> Michael Turner writes: >>> >>> > Another objection raised against this syntax change is that all >>> > functional languages violate DRY in this manner, so it's OK if Erlang >>> > does it too. This is a Principle of Least Surprise argument, and not >>> > bad as far as it goes. But how far does it go? >>> > >>> > Erlang will have a better chance of greater success and survival if you >>> > consider your recruitment base to be the overwhelming majority of >>> > programmers. And from what I can tell, >>> > >>> > http://www.langpop.com >>> > >>> > the overwhelming majority of programmers have no experience to speak >>> > of, when it comes to functional programming languages. Appealing to the >>> > "cross-training" benefit of coming from other FP languages seems like a >>> > pretty weak argument. Especially since all I'm asking for here is >>> > syntactic consistency *within* Erlang -- a PLoS argument in itself. >>> > >>> > Richard O'Keefe suggests that the syntactic consistency goal is better >>> > met by allowing a kind of limited-scope special-case fun name, >>> > permitting, e.g. >>> > >>> > Fact = fun F(0) -> 1; F(N) -> N*F(N-1) end. >>> > >>> > I could get behind that too, but I don't follow his reasoning from >>> > syntactic consistency, which is apparently that an unnamed fun has a >>> > name, it's just the degenerate case of a name. It's really there. We >>> > just can't see it. Hm, really? If that were true in Erlang as it >>> > stands, shouldn't I be able to write it this way? >>> > >>> > Fact = fun (0) -> 1; (N) -> N*''(N-1) end. >>> > >>> > Looks like it's not quite that simple. It compiles, but it doesn't know >>> > what module to look in for '', when it comes time to execute. In the >>> > shell, I get an error indicating that it tried to resolve ''/1 as a >>> > shell command. Even if I put it in a .erl file and compile it, there's >>> > no obvious way to tell the compiler what module to look in. ?MODULE:'' >>> > doesn't work. Nor does '':'', which I tried just for the hell of it. >>> > >>> > What Richard's suggesting appears to require a rigorous re-think of how >>> > scopes are defined in Erlang. What I'm suggesting amounts to simply >>> > asking the compiler to do some of your tedious keying for you. >>> > >>> > -michael turner >>> > >>> > >>> > On Wed, May 18, 2011 at 6:16 PM, Michael Turner < >>> > michael.eugene.turner@REDACTED> wrote: >>> > >>> > I can say >>> > >>> > fun (1)->2; >>> > (2)->1 >>> > end >>> > >>> > but, oddly, I can't define a named function in the analogous way, >>> > e.g.: >>> > >>> > factorial >>> > (1) -> 1; >>> > (N) -> N*factorial(N-1). >>> > >>> > gives me a syntax error. I find the latter more readable than >>> > >>> > factorial(1) -> 1; >>> > factorial(2) -> N*fact(N-1). >>> > >>> > It's also less to type and to read, which is consistent with the >>> > DRY principle ("Don't Repeat Yourself"). And it lends itself to >>> > reading a function definition as a set of cases. I think for Erlang >>> > newbies, it should therefore would be preferred: it helps >>> > underscore the pattern-matching style of Erlang function >>> > invocation. >>> > >>> > It also looks a *little* bit more like the mathematical convention >>> > for defining these sorts of functions, where you have "f(x) = ", >>> > centered vertically to the left of a big left "{" that (left-) >>> > encloses the list of expression/parameter-condition pairs in a >>> > two-column format, e.g., >>> > >>> > http://cnx.org/content/m29517/latest/Picture%2047.png >>> > >>> > So there's a (weak) argument from the Principle of Least Surprise >>> > here as well. >>> > >>> > It seems to me that, if anything, this requires only a >>> > *simplification* of the Erlang parser. That leaves only one obvious >>> > objection: would any existing code break if Erlang syntax were >>> > altered to allow this? >>> > >>> > -michael turner >>> > >>> > _______________________________________________ >>> > erlang-questions mailing list >>> > erlang-questions@REDACTED >>> > http://erlang.org/mailman/listinfo/erlang-questions >>> >>> - -- >>> Parnell "ixmatus" Springmeyer (http://ixmat.us) >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG/MacGPG2 v2.0.17 (Darwin) >>> Comment: GPGTools - http://gpgtools.org >>> >>> iQEcBAEBAgAGBQJN0+XsAAoJEPvtlbpI1POLEXEIAJrjAGVTkveBi5/akYNMjBEX >>> 8wI9twatnXh8sfg2ohGKr3P1hj4jTr9ARrG5wiB9OCArRkBymnjFeY5g2dkBDOhN >>> aN722l+yDPpUewAM58m0dDoDHjrHXvxF1MJejQJGhQ+Nr9fM+7G+4QIrCN9RvX1S >>> QTAS+OqOnl8lsS98yvUiXXLB5ehdHcR46Ix6Sq7UwSvqaOKZMoPrzkTtW3VyS5kf >>> i/uGbPZ1I3KQJYRShk2QlLis/tpXGtLDnYc1E5uADqeClDXy5Au6LWpNqUjNIiWw >>> h8I2emcBq5Ur7nivNUYgnVMjg+0qTkQOtttPpOJ25xIYv07L+eMfXneb5nRx4hc= >>> =GGPU >>> -----END PGP SIGNATURE----- >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >> >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrtndimitrov@REDACTED Thu May 19 21:07:34 2011 From: mrtndimitrov@REDACTED (Martin Dimitrov) Date: Thu, 19 May 2011 22:07:34 +0300 Subject: [erlang-questions] call by value In-Reply-To: References: <4DD538E2.70107@gmail.com> Message-ID: <4DD56A76.1050303@gmail.com> Thanks for the explanation. Now I am glad I asked that question. I had always thought of call-by-value as the actual act of copying the value which now I understand it might be or might not be as in the case with Erlang. Regards, Martin On 5/19/2011 7:23 PM, Jesper Louis Andersen wrote: > On Thu, May 19, 2011 at 17:36, Martin Dimitrov wrote: > >> "All calls with variables in Erlang are call by value: all arguments to >> a function call are evaluated before the body of the function is >> evaluated. The concept of call by reference does not exist, ..." > I'll reply even though others have replied and add a bit more flesh. > Suppose we have a function: > > f(X) -> > X + 7. > > and we want to call it like this: > > f(3 + 5), > > now there are two ways the reduction can proceed. Either we first > evaluate the expression and then make the call, > > f(3 + 5) ==> f(8) ==> 8 + 7 ==> 15 > > which is the call-by-value evaluation strategy, or we do it by > substituting in the expression first, > > f(3 + 5) ==> (3 + 5) + 7 ==> 8 + 7 ==> 15 > > which is the call-by-reference evaluation strategy. Erlang is a > Call-by-value (or an eager/strict) language. Clean and Haskell are > good examples of languages that use a variant the call-by-reference > strategy named call-by-need. > > You may be confusing the evaluation strategy with whether parameters > are passed by value or by reference. This is an important notion in an > imperative language like Java, C, C++, Go, etc, but in functional > languages pass-by-value is the only thing you can do. Remember though > that in a functional language values are persistent and thus > immutable. Hence, we can get away with reusing the same in-memory > structure over and over again until we change it. And when we do > change it, we can exploit to share as much as possible from the old > structure. We define > > L = [1], > > with an in-memory representation like this: > > {P1} ==> [] > > where P1 is a pointer to a cell containing the value 1 and ===> is a > pointer and [] is a special value signifying the end-of-list. Now, if > cons it two times: > > L2 = [2 | L], > L3 = [3 | L], > > We get two lists like this: > > {P2} ====\ > {P1} ==> [] > {P3} ====/ > > My ASCII-art hopefully showing how the L2 and L3 lists share the tail. > Immutability like this means we can just pass a reference and that is > as good as having made a copy of the whole data structure. It can be > exploited by your programs giving you some possibilities which are > quite funny to think about. For instance: > > X = 3, > L = {X, X} > L2 = {L, L}, > L3 = {L2, L2}, > L4 = {L3, L3}, > L5 = {L4, L4}. > > L5 is built in linear time and contains 32 X cells. That is, we just > built an exponentially large data structure in linear time. Also, all > of it references the same X in memory. Yet if we ask for the sum of > the tree-like structure, then we would get the correct answer of 32 * > 3. > > So in conclusion: everything is passed by value, but where possible, > Erlang will pass by reference due to the immutable behaviour of the > Erlang heap. So the whole question of the passing style > (value/refence) is specific the implementation and not needed to > understand how the language evaluates (everything is pass-by-value). > >> I know that variables are not copied when making a function call and are >> copied when sending messages to processes. So why do the authors say all >> calls are call by value? Aren't the function calls actually call by >> reference? > Yes, when you send a message to another process, Erlang has to move > the structure you are sending to the other process. This is because > processes have separate heaps, so you must somehow move the data from > one heap to the other and copying is the quickest/simplest way to do > that. Storing and retrieving data from/to ETS has the same copying. > From dang@REDACTED Thu May 19 21:22:15 2011 From: dang@REDACTED (Daniel Goertzen) Date: Thu, 19 May 2011 14:22:15 -0500 Subject: [erlang-questions] supervisor children's pid In-Reply-To: References: <20110518044824.GC7320@aluminum.local> <20110518083422.GB1762@hanele.lan> Message-ID: Also +1 for gproc. In your supervisor child specs, pass the supervisor's pid as a parameter to each gen_server. Then, have the gen_servers register themselves with gproc as.. {SuperPid, child1} {SuperPid, child2} etc... This way siblings can easily access each other even after child restarts, and you can have many instances of your supervisor/gen_server tree without registration collisions (which I suspect is why you avoided registration to begin with.) Also, see gproc:await() to synchronize startup with siblings. Dan. On Wed, May 18, 2011 at 7:45 AM, Tim Watson wrote: > >> > >> * Run a name resolution server somewhere and have all the children > >> subscribe to it. The server will monitor them and may provide > >> notification facility to announce Pid changes/availability to > >> anyone interested -- this lets you do safe startup of dependent > >> processes. > > > > probably the best would be then to have a gen_event module for this. this > is > > a good idea. > > > > wouldn't gproc be useful for this? The keys don't have to matter and > you can subscribe based on a match/wildcard. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Daniel Goertzen ----------------- dang@REDACTED (work) daniel.goertzen@REDACTED (home) ----------------- 1 204 272 6149 (home/office) 1 204 470 8360 (mobile) ----------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jameschurchman@REDACTED Thu May 19 22:02:28 2011 From: jameschurchman@REDACTED (James Churchman) Date: Thu, 19 May 2011 21:02:28 +0100 Subject: [erlang-questions] Advanced Erlang Subtleties Message-ID: Mondays's excellent London User Group about Misultin ( by Roberto Ostinelli ) brought up many fascinating discussions, one was about supervisors vs custom rolling the functionality & storing Pids in an Ets table due to supervisors storing children as a list, how to make Misultin 0.8 OTP compatible but still quick to get started with & directly embeddable etc.. One thing I decided to after one convocation was to document all the erlang syntax ( eg, no otp ) subtleties or bits i find counter-intuitive i have discovered, for the use of others & also to prompt the occasional "why was it implemented this way" out of anybody who knows. None of this is a criticism ( and some is point out things that are lesser used and i very much like), as so far i have found erlang to have very few inconsistencies,including in error conditions!, but knowing all the subtleties for any language I use is a personal favourite of mine ( coming from js gives you that! ) so here we go : *A) List Comprehension are personally my favourite part of erlang, but have the most subtleties of anything, partially because they pack a lot of functionality in a tiny bit of syntax : 1) LC's act as a list filter, then list map therefore : List = [{a,b},{c,d,e,f},{h,i}] [I1||{I1,I2}<-List] will not crash but instead filter out the 4 elem tuple. This is great, but where is the opposite version of a LC that is only a map and will crash ? The standard behaviour seems to go against "let it crash" & on a few occasions have had code that gives a final [] rather than the output expected. Using : [fun({I1,I2}) -> I1 end(Elem)||Elem<-List] or [begin {I1,I2}=Elem, I1 end||Elem<-List] give a behaviour equivalent to a list map but are less elegant than a : [I1||{I1,I2}<---List] or something similar. ( notice the <--- ) I would really welcome this addition to the language ( and many many many user i have met presume this is the default behaviour for a LC :-) 2) List comprehensions can't normally contain multiple statements, possibly because it might confuse users that [do(),do2(),do3()||_<-List] would add three elements to a list each time (that syntax could be really useful to do that tho!). You can however use the "begin end", also shown above, syntax like : [begin do(),do2(),do3() end ||_<-List] to make it all "one statement" (and you will end up with a list of the results of do3()). 3) This, i feel, is a VERY annoying scoping bug : OuterVar = 'a', List = [{a,b},{c,d},{e,f}], Y : [I2||{OuterVar,I2}<-List] Z : [I2||{I1,I2}<-List when I1==OuterVar] these do not produce the same result. in "Y:" the "OuterVar" gets overridden, not matched, so you end up with every element matching. In "Z: " it behaves (as "Y:" should) ad filters out all but the matches with 'a' this is unlike a case where case input of Input -> ok; _ -> other end, will give ok but if you set Input before to be say 'not_an_input_atom' it will give 'other' I hate this behaviour... :-) 4) you can produce generatorless LC's these act like a "if the entire list does not match the guards replace with an empty list otherwise return it".. they look crazy! but can be useful when generating iolists (or *not* iolists :-) to avoid case statements 5) custom guards and error handling : after much thought i feel this is the correct behaviour, though it's surprising : List = [1,2,three,4,5], Y : [I1||I1<-List when I1+1>0 ] Z : Guard = fun(I1) -> I1+1>0 end, [I1||I1<-List when Guard(I1)] "Y :" will filter out 'three' and "Z : " will crash, and importantly crashes when it hits 'three' and not before. same code! however having guards that rerun false rather than crash prevents complex is_type() etc.. whereas, when you call you could be calling huge functions, even with side effects ; silencing all that makes no sense. It also allows you to make guards that crash, so make the code a tad less defensive. 6) list comprehensions crash with an invalid list, but only when it reaches the tail element : [io:format("~p~n",[Elem])||Elem<-[1,2,3,4|invalid_tail]] will first print out 1 to 4, then crash *B) variable name repetition matchings : you can write : function_name(Elem1,Elem1)->this_matches; function_name(Elem1,Elem2)->this_does_not_match; and when you put function_name(100,100) it will match. this may seem obvious but in many cases it can reduce a lot of code where otherwise you are writing guards or dropping into a case, especially when you have more complex disassembly pattern matches combined with recursion. I use this in much of my code, as it feels more functional than lots of == or case etc.. :-) *C) pattern matches can be anywhere All things in erlang always return, even pattern matches which return themselves so : [elem1,Var1 = elem2,elem3] will give the list [elem1,elem2,elem3] but also set Var1 to elem2. In a more complex case this can (with reasonable use) reduce code a lot as it lets you change the order you build up code, so the last element that returns is the one you want.. you don't need to build up an intermediate value, do some code, then place that var at the end to return. They can also be used in function heads like : function(Elem1={_,_,_})-> Elem. *D) "begin end" statements can be anywhere this can be used to embed more than one statement when building a list etc : [elem1, elem2, begin {Elem3,_,_,_ } = fetch_elem3(), Elem3 end, elem4] its also possible to put case, if etc.. ( as everything in erlang returns) statements there too like : [elem1, elem2, case Elem3 of _ when is_atom(Elem3) -> atom_to_list(Elem3) _ -> Elem3 end, elem4] *E) case ( and other like try catch etc.. ) drop their matched variables out the bottom ( eg they stay in scope even after they are used) case input_atom of Input -> ok; _ -> other end, Input is now still 'input_atom' *F) Operators have Type Precedence "hello < 10" etc.. does not throw but returns false. the atom 'aaa' is less than the atom 'aab' etc.. There may be small use cases for this like implementing generic sorting functions etc.. but 99% of the time if you magnitude compare two different types ( without intermediate type conversion, and ignoring float/int differences) this is a huge bug in your code. I can see the equivalent evaluation of "250"<250 being a common mistake, and always being false is hardly useful. Also this behaviour can hardly help the dialyser spot common type mistakes as this is valid code. Does this ever prove to be a big problem in large scale systems? or not really? or does producing a module full of : '>'(I1,I2) when is_number(I1), is_number(I2) -> I1>I2. ( '>' could be "greater_than" or "gt" or similar) which crashes on non numeric input produce helpful crashes at the point of error? or just overkill? *G) {module,function}(Inputs) The tuple pair can be used as a way of calling functions, tho the recommended style is: fun mod:funct/arity but still fun to know. *H) Funs can be self executing by wrapping () after them like : fun (FunInput) -> some_code() end(Input) *J) try/catch: 1) - in the ERROR_TYPE:ERROR catch the throw: can be left out, and it means the same as catching a throw of type "Error".. nice short hand. There is also a 3rd parameter in the AST that is always a match all ( a bit like ERROR_TYPE:ERROR:_ ) does anybody know what this means? is there an extra option in a catch? ( maybe everybody knows these last few but just to be sure ) 2) if nothing matches in the catch statements the error propagates up as if there was no try catch at all, very useful and stops the need for re-throwing like other languages! 3) in the try Code of ... catch the "of" is optional & returns the CODE value if left out, also ( maybe v obvious) the code in the "of" section is not caught 4) the old, strange and broken "catch" requires wrapping in parens if you want its return value: Var = catch throw(100). seems to be a syntax error Var = (catch throw(100)). is fine also distinguishing between certain throws and an ordinary return can be impossible. *K) records ( this got too long so I made it a follow on email :-) basically I wish to write a (better) parse transform fix ) If after corrections/some extra suggestions someone wants to put this on their blog then feel free, I don't have one :-) James -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Thu May 19 23:02:35 2011 From: erlang@REDACTED (Joe Armstrong) Date: Thu, 19 May 2011 23:02:35 +0200 Subject: [erlang-questions] Advanced Erlang Subtleties In-Reply-To: References: Message-ID: On Thu, May 19, 2011 at 10:02 PM, James Churchman wrote: > Mondays's excellent London User Group about Misultin ( by Roberto Ostinelli > ) brought up many fascinating discussions, one was about supervisors vs > custom rolling the functionality & storing Pids in an Ets table due to > supervisors storing children as a list, how to make Misultin 0.8 OTP > compatible but still quick to get started with & directly embeddable etc.. > > One thing I decided to after one convocation was to document all the erlang > syntax ( eg, no otp ) subtleties or bits i find counter-intuitive i have > discovered, for the use of others & also to prompt the occasional "why was > it implemented this way" out of anybody who knows. None of this is a > criticism ( and some is point out things that are lesser used and i very > much like), as so far i have found erlang to have very few > inconsistencies,including in error conditions!, but knowing all the > subtleties for any language I use is a personal favourite of mine ( coming > from js gives you that! ) > > so here we go : > > *A) List Comprehension are personally my favourite part of erlang, but have > the most subtleties of anything, partially because they pack a lot of > functionality in a tiny bit of syntax : > > 1) LC's act as a list filter, then list map > therefore : > List = [{a,b},{c,d,e,f},{h,i}] > [I1||{I1,I2}<-List] will not crash but instead filter out the 4 elem tuple. > This is great, but where is the opposite version of a LC that is only a map > and will crash ? > lists:map(fun({I,J}) -> I end, List) it is "only a map" :-) > The standard behaviour seems to go against "let it crash" & on a few > occasions have had code that gives a final [] rather than the output > expected. > Using : > [fun({I1,I2}) -> I1 end(Elem)||Elem<-List] > But this does crash and does not produce [] 1> L = [{1,2},{3,4},{1,2,3,4}]. [{1,2},{3,4},{1,2,3,4}] 2> [fun({I,J})->I end(E) || E <- L]. ** exception error: no function clause matching erl_eval:'-inside-an-interpreted-fun-'({1,2,3,4}) same in compiled code - I checked > or > [begin {I1,I2}=Elem, I1 end||Elem<-List] > give a behaviour equivalent to a list map but are less elegant than a : > [I1||{I1,I2}<---List] or something similar. ( notice the <--- ) > I would really welcome this addition to the language ( and many many many > user i have met presume this is the default behaviour for a LC :-) > > 2) List comprehensions can't normally contain multiple statements, possibly > because it might confuse users that [do(),do2(),do3()||_<-List] would add > three elements to a list each time (that syntax could be really useful to do > that tho!). You can however use the "begin end", also shown above, syntax > like : [begin do(),do2(),do3() end ||_<-List] to make it all "one statement" > (and you will end up with a list of the results of do3()). > It's a grammar thing. It's extremely difficult (impossible?) to write a grammar where you can put a sequences of forms at any place where a single form is expected - this is what begin .. end is for it's like the lisp (progn a b c) which evaluates a b and c in order and whose result is c. > > 3) This, i feel, is a VERY annoying scoping bug : > > OuterVar = 'a', List = [{a,b},{c,d},{e,f}], > > Y : [I2||{OuterVar,I2}<-List] > > Z : [I2||{I1,I2}<-List when I1==OuterVar] > > these do not produce the same result. > > It's a feature :-) > in "Y:" the "OuterVar" gets overridden, not matched, so you end up with > every element matching. In "Z: " it behaves (as "Y:" should) ad filters out > all but the matches with 'a' > this is unlike a case where > case input of Input -> ok; _ -> other end, > will give ok but if you set Input before to be say 'not_an_input_atom' it > will give 'other' > > I hate this behaviour... :-) > > 4) you can produce generatorless LC's > these act like a "if the entire list does not match the guards replace with > an empty list otherwise return it".. they look crazy! but can be useful when > generating iolists (or *not* iolists :-) to avoid case statements > > 5) custom guards and error handling : > after much thought i feel this is the correct behaviour, though it's > surprising : > > List = [1,2,three,4,5], > > Y : [I1||I1<-List when I1+1>0 ] > > Z : Guard = fun(I1) -> I1+1>0 end, > [I1||I1<-List when Guard(I1)] > > "Y :" will filter out 'three' and "Z : " will crash, and importantly > crashes when it hits 'three' and not before. same code! however having > guards that rerun false rather than crash prevents complex is_type() etc.. > whereas, when you call you could be calling huge functions, even with side > effects ; silencing all that makes no sense. It also allows you to make > guards that crash, so make the code a tad less defensive. > > 6) list comprehensions crash with an invalid list, but only when it reaches > the tail element : > [io:format("~p~n",[Elem])||Elem<-[1,2,3,4|invalid_tail]] > will first print out 1 to 4, then crash > > > *B) variable name repetition matchings : > > you can write : > function_name(Elem1,Elem1)->this_matches; > function_name(Elem1,Elem2)->this_does_not_match; > > and when you put function_name(100,100) it will match. this may seem > obvious but in many cases it can reduce a lot of code where otherwise you > are writing guards or dropping into a case, especially when you have more > complex disassembly pattern matches combined with recursion. I use this in > much of my code, as it feels more functional than lots of == or case etc.. > :-) > > > *C) pattern matches can be anywhere > All things in erlang always return, even pattern matches which return > themselves so : > > [elem1,Var1 = elem2,elem3] will give the list [elem1,elem2,elem3] but also > set Var1 to elem2. In a more complex case this can (with reasonable use) > reduce code a lot as it lets you change the order you build up code, so the > last element that returns is the one you want.. you don't need to build up > an intermediate value, do some code, then place that var at the end to > return. > > They can also be used in function heads like : > function(Elem1={_,_,_})-> Elem. > This is very useful I use this all the time Suppose I want to do this foo({a,{b,X},c}) -> bar({b,X}) Better is foo({a,{b,X}=Z,c}) -> bar(Z). which avoids reconstructing the {b,X} term and is 2 characters shorter and reduces the possibility of error if the subterm is large > > *D) "begin end" statements can be anywhere > > this can be used to embed more than one statement when building a list etc > : > [elem1, > elem2, > begin > {Elem3,_,_,_ } = fetch_elem3(), > Elem3 > end, > elem4] > > its also possible to put case, if etc.. ( as everything in erlang returns) > statements there too like : > [elem1, > elem2, > case Elem3 of > _ when is_atom(Elem3) -> atom_to_list(Elem3) > _ -> Elem3 > end, > elem4] > > *E) case ( and other like try catch etc.. ) drop their matched variables > out the bottom ( eg they stay in scope even after they are used) > case input_atom of Input -> ok; _ -> other end, > Input is now still 'input_atom' > > *F) Operators have Type Precedence > "hello < 10" etc.. does not throw but returns false. > the atom 'aaa' is less than the atom 'aab' etc.. > > There may be small use cases for this like implementing generic sorting > functions etc.. but 99% of the time if you magnitude compare two different > types ( without intermediate type conversion, and ignoring float/int > differences) this is a huge bug in your code. > Disagree - having a total order over all terms means it is possible to write extremely useful generic functions. Key-Value stores for example (llke dicts and ets tables) would be very difficult to implement without this > > I can see the equivalent evaluation of "250"<250 being a common mistake, > and always being false is hardly useful. > A "<" B when A and B have different types means A is "less complex" than B. Lists and more complex than integers "250" is a list so "250"<250 is false. Suppose I want to make a Key-Value database, where the Key can be anything, including 250 and "250" to make any form of ordered tree we need a total order over all the keys. > Also this behaviour can hardly help the dialyser spot common type mistakes > as this is valid code. Does this ever prove to be a big problem in large > scale systems? or not really? or does producing a module full of : > > '>'(I1,I2) when is_number(I1), is_number(I2) -> I1>I2. ( '>' could be > "greater_than" or "gt" or similar) > which crashes on non numeric input produce helpful crashes at the point of > error? or just overkill? > > *G) {module,function}(Inputs) > The tuple pair can be used as a way of calling functions, tho the > recommended style is: fun mod:funct/arity but still fun to know. > > *H) Funs can be self executing by wrapping () after them like : fun > (FunInput) -> some_code() end(Input) > > *J) try/catch: > 1) - in the ERROR_TYPE:ERROR catch the throw: can be left out, and it means > the same as catching a throw of type "Error".. nice short hand. > There is also a 3rd parameter in the AST that is always a match all ( a bit > like ERROR_TYPE:ERROR:_ ) does anybody know what this means? is there an > extra option in a catch? > > ( maybe everybody knows these last few but just to be sure ) > 2) if nothing matches in the catch statements the error propagates up as if > there was no try catch at all, very useful and stops the need for > re-throwing like other languages! > 3) in the try Code of ... catch the "of" is optional & returns the CODE > value if left out, also ( maybe v obvious) the code in the "of" section is > not caught > 4) the old, strange and broken "catch" requires wrapping in parens if you > want its return value: > Var = catch throw(100). seems to be a syntax error > Var = (catch throw(100)). is fine > also distinguishing between certain throws and an ordinary return can be > impossible. > > *K) records > ( this got too long so I made it a follow on email :-) basically I wish to > write a (better) parse transform fix ) > > If after corrections/some extra suggestions someone wants to put this on > their blog then feel free, I don't have one :-) > James > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Thu May 19 23:08:49 2011 From: erlang@REDACTED (Joe Armstrong) Date: Thu, 19 May 2011 23:08:49 +0200 Subject: [erlang-questions] [erlang-bugs] Bad object error in dets in R14B02 In-Reply-To: References: Message-ID: Brilliant - worth a slide in a lecture Here is code (dets) that is 1) battle tested 2) impossible to prove correct 3) highly tested 4) believed reliable but nevertheless buggy and you find the bug even though it has not been reported. /Joe On Mon, May 16, 2011 at 6:23 PM, John Hughes wrote: > QuickCheck found another error in dets. The following test case shows how > to provoke a bad object error by starting three concurrent match_object > traversals, at the same time as data is inserted into the table. > > test() -> > dets:close(dets_table), > file:delete(dets_table), > {ok,dets_table} = dets:open_file(dets_table,[{type,bag}]), > ok = dets:insert(dets_table,[{0,0},{0,14},{1,0},{1,1},{39,0}]), > {[{0,14}],Cont} = dets:match_object(dets_table,{'$1',14},0), > ok = dets:insert(dets_table,{2,0}), > {[{0,0},{0,14}],_} = dets:match_object(dets_table,{0,'$2'},0), > ok = dets:insert(dets_table,[{2,1},{39,1}]), > {[{1,0}],_} = dets:match_object(dets_table,{'$1',0},0), > {error,{{bad_object,scan},"dets_table"}} = dets:match_object(Cont). > > This is 100% repeatable--and it seems to be a minimal example. > > John > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jameschurchman@REDACTED Thu May 19 23:42:54 2011 From: jameschurchman@REDACTED (James Churchman) Date: Thu, 19 May 2011 22:42:54 +0100 Subject: [erlang-questions] Advanced Erlang Subtleties In-Reply-To: References: Message-ID: > > But this does crash and does not produce [] > > 1> L = [{1,2},{3,4},{1,2,3,4}]. > [{1,2},{3,4},{1,2,3,4}] > 2> [fun({I,J})->I end(E) || E <- L]. > ** exception error: no function clause matching > erl_eval:'-inside-an-interpreted-fun-'({1,2,3,4}) > > > same in compiled code - I checked > yes that's what i ment ( sorry if i was unclear), you have to place a fun or a "begin match end" in to make it crash :-) but it would be nice to have a "map" equivalent to LC's that had a small ( but cear ) syntax difference. ( when i worry about this i tend to [begin {I1,I2}=Elem, I1 end||Elem<-List] rather than use list map or self executing fun .. :-) > It's a grammar thing. It's extremely difficult (impossible?) to > write a grammar where you can put a sequences of forms > at any place where a single form is expected - this is what > begin .. end is for it's like the lisp (progn a b c) which evaluates > a b and c in order and whose result is c. > i see v interesting! not a problem tho as an extra begin end fixes it! > 3) This, i feel, is a VERY annoying scoping bug : >> >> OuterVar = 'a', List = [{a,b},{c,d},{e,f}], >> >> Y : [I2||{OuterVar,I2}<-List] >> >> Z : [I2||{I1,I2}<-List when I1==OuterVar] >> >> these do not produce the same result. >> > > It's a feature :-) > really?? it seems totally inconstant to the rest of erlang to me .. tho il take your word for it. it just annoys me especially as the vars in the guards even get effected by this "overwriting" behaviour. I guess its just my personal style that shows it up. This is very useful I use this all the time > > Suppose I want to do this > > foo({a,{b,X},c}) -> bar({b,X}) > > Better is > > foo({a,{b,X}=Z,c}) -> bar(Z). > > > which avoids reconstructing the {b,X} term and is 2 characters shorter > and reduces the possibility of error if the subterm is large > i agree entirely:-)... problem with email is its hard to convey what you mean... i like this a huge amount! fair bit of erlang code i see does not "= p-match" in the function head when it could.. - Show quoted text - Thats a very good point that I had not thought of the hash maps case... it still leads to errors tho and makes erlang feel a bit like a loosely typed language in that regard. My question i guess was more have other ppl hit this silent error (which can be hard to trace) or have large products produced numeric only comparison modules? if you start off with say xml etc.. its easy to forget a list_to_integer() and the comparisons don't throw you just get weird results! The main point of the email was i had never seen a detailed list of all the less known syntax features and thought it would interest the list :-) most of the above are great features ( apart from the lack of map LC's :-) ) so i guess many thanks for that joe! james On 19 May 2011 22:02, Joe Armstrong wrote: > > > On Thu, May 19, 2011 at 10:02 PM, James Churchman < > jameschurchman@REDACTED> wrote: > >> Mondays's excellent London User Group about Misultin ( by Roberto >> Ostinelli ) brought up many fascinating discussions, one was about >> supervisors vs custom rolling the functionality & storing Pids in an Ets >> table due to supervisors storing children as a list, how to make Misultin >> 0.8 OTP compatible but still quick to get started with & directly embeddable >> etc.. >> >> One thing I decided to after one convocation was to document all the >> erlang syntax ( eg, no otp ) subtleties or bits i find counter-intuitive i >> have discovered, for the use of others & also to prompt the occasional "why >> was it implemented this way" out of anybody who knows. None of this is a >> criticism ( and some is point out things that are lesser used and i very >> much like), as so far i have found erlang to have very few >> inconsistencies,including in error conditions!, but knowing all the >> subtleties for any language I use is a personal favourite of mine ( coming >> from js gives you that! ) >> >> so here we go : >> >> *A) List Comprehension are personally my favourite part of erlang, but >> have the most subtleties of anything, partially because they pack a lot of >> functionality in a tiny bit of syntax : >> >> 1) LC's act as a list filter, then list map >> therefore : >> List = [{a,b},{c,d,e,f},{h,i}] >> [I1||{I1,I2}<-List] will not crash but instead filter out the 4 elem >> tuple. This is great, but where is the opposite version of a LC that is only >> a map and will crash ? >> > > lists:map(fun({I,J}) -> I end, List) > > it is "only a map" > > :-) > > > > >> The standard behaviour seems to go against "let it crash" & on a few >> occasions have had code that gives a final [] rather than the output >> expected. >> Using : >> [fun({I1,I2}) -> I1 end(Elem)||Elem<-List] >> > > But this does crash and does not produce [] > > 1> L = [{1,2},{3,4},{1,2,3,4}]. > [{1,2},{3,4},{1,2,3,4}] > 2> [fun({I,J})->I end(E) || E <- L]. > ** exception error: no function clause matching > erl_eval:'-inside-an-interpreted-fun-'({1,2,3,4}) > > > same in compiled code - I checked > > > >> or >> [begin {I1,I2}=Elem, I1 end||Elem<-List] >> give a behaviour equivalent to a list map but are less elegant than a : >> [I1||{I1,I2}<---List] or something similar. ( notice the <--- ) >> I would really welcome this addition to the language ( and many many many >> user i have met presume this is the default behaviour for a LC :-) >> >> 2) List comprehensions can't normally contain multiple statements, >> possibly because it might confuse users that [do(),do2(),do3()||_<-List] >> would add three elements to a list each time (that syntax could be really >> useful to do that tho!). You can however use the "begin end", also shown >> above, syntax like : [begin do(),do2(),do3() end ||_<-List] to make it all >> "one statement" >> (and you will end up with a list of the results of do3()). >> > > It's a grammar thing. It's extremely difficult (impossible?) to > write a grammar where you can put a sequences of forms > at any place where a single form is expected - this is what > begin .. end is for it's like the lisp (progn a b c) which evaluates > a b and c in order and whose result is c. > > >> >> 3) This, i feel, is a VERY annoying scoping bug : >> >> OuterVar = 'a', List = [{a,b},{c,d},{e,f}], >> >> Y : [I2||{OuterVar,I2}<-List] >> >> Z : [I2||{I1,I2}<-List when I1==OuterVar] >> >> these do not produce the same result. >> >> > It's a feature :-) > > >> in "Y:" the "OuterVar" gets overridden, not matched, so you end up with >> every element matching. In "Z: " it behaves (as "Y:" should) ad filters out >> all but the matches with 'a' >> this is unlike a case where >> case input of Input -> ok; _ -> other end, >> will give ok but if you set Input before to be say 'not_an_input_atom' it >> will give 'other' >> >> I hate this behaviour... :-) >> >> 4) you can produce generatorless LC's >> these act like a "if the entire list does not match the guards replace >> with an empty list otherwise return it".. they look crazy! but can be useful >> when generating iolists (or *not* iolists :-) to avoid case statements >> >> 5) custom guards and error handling : >> after much thought i feel this is the correct behaviour, though it's >> surprising : >> > >> List = [1,2,three,4,5], >> >> Y : [I1||I1<-List when I1+1>0 ] >> >> Z : Guard = fun(I1) -> I1+1>0 end, >> [I1||I1<-List when Guard(I1)] >> >> "Y :" will filter out 'three' and "Z : " will crash, and importantly >> crashes when it hits 'three' and not before. same code! however having >> guards that rerun false rather than crash prevents complex is_type() etc.. >> whereas, when you call you could be calling huge functions, even with side >> effects ; silencing all that makes no sense. It also allows you to make >> guards that crash, so make the code a tad less defensive. >> >> 6) list comprehensions crash with an invalid list, but only when it >> reaches the tail element : >> [io:format("~p~n",[Elem])||Elem<-[1,2,3,4|invalid_tail]] >> will first print out 1 to 4, then crash >> >> >> *B) variable name repetition matchings : >> >> you can write : >> function_name(Elem1,Elem1)->this_matches; >> function_name(Elem1,Elem2)->this_does_not_match; >> >> and when you put function_name(100,100) it will match. this may seem >> obvious but in many cases it can reduce a lot of code where otherwise you >> are writing guards or dropping into a case, especially when you have more >> complex disassembly pattern matches combined with recursion. I use this in >> much of my code, as it feels more functional than lots of == or case etc.. >> :-) >> >> >> *C) pattern matches can be anywhere >> All things in erlang always return, even pattern matches which return >> themselves so : >> >> [elem1,Var1 = elem2,elem3] will give the list [elem1,elem2,elem3] but also >> set Var1 to elem2. In a more complex case this can (with reasonable use) >> reduce code a lot as it lets you change the order you build up code, so the >> last element that returns is the one you want.. you don't need to build up >> an intermediate value, do some code, then place that var at the end to >> return. >> >> They can also be used in function heads like : >> function(Elem1={_,_,_})-> Elem. >> > > This is very useful I use this all the time > > Suppose I want to do this > > foo({a,{b,X},c}) -> bar({b,X}) > > Better is > > foo({a,{b,X}=Z,c}) -> bar(Z). > > > which avoids reconstructing the {b,X} term and is 2 characters shorter > and reduces the possibility of error if the subterm is large > > >> >> *D) "begin end" statements can be anywhere >> >> this can be used to embed more than one statement when building a list etc >> : >> [elem1, >> elem2, >> begin >> {Elem3,_,_,_ } = fetch_elem3(), >> Elem3 >> end, >> elem4] >> >> its also possible to put case, if etc.. ( as everything in erlang returns) >> statements there too like : >> [elem1, >> elem2, >> case Elem3 of >> _ when is_atom(Elem3) -> atom_to_list(Elem3) >> _ -> Elem3 >> end, >> elem4] >> >> *E) case ( and other like try catch etc.. ) drop their matched variables >> out the bottom ( eg they stay in scope even after they are used) >> case input_atom of Input -> ok; _ -> other end, >> Input is now still 'input_atom' >> >> *F) Operators have Type Precedence >> "hello < 10" etc.. does not throw but returns false. >> the atom 'aaa' is less than the atom 'aab' etc.. >> >> There may be small use cases for this like implementing generic sorting >> functions etc.. but 99% of the time if you magnitude compare two different >> types ( without intermediate type conversion, and ignoring float/int >> differences) this is a huge bug in your code. >> > > Disagree - having a total order over all terms means it is > possible to write extremely useful generic functions. Key-Value > stores for example (llke dicts and ets tables) would be > very difficult to implement without this > > >> >> I can see the equivalent evaluation of "250"<250 being a common mistake, >> and always being false is hardly useful. >> > > A "<" B when A and B have different types means A is > "less complex" than B. Lists and more complex than integers > "250" is a list so "250"<250 is false. > > Suppose I want to make a Key-Value database, where the Key can be anything, > including 250 and "250" to make any form of ordered tree we need a total > order over all the keys. > > > >> Also this behaviour can hardly help the dialyser spot common type mistakes >> as this is valid code. Does this ever prove to be a big problem in large >> scale systems? or not really? or does producing a module full of : >> >> '>'(I1,I2) when is_number(I1), is_number(I2) -> I1>I2. ( '>' could be >> "greater_than" or "gt" or similar) >> which crashes on non numeric input produce helpful crashes at the point of >> error? or just overkill? >> >> *G) {module,function}(Inputs) >> The tuple pair can be used as a way of calling functions, tho the >> recommended style is: fun mod:funct/arity but still fun to know. >> >> *H) Funs can be self executing by wrapping () after them like : fun >> (FunInput) -> some_code() end(Input) >> >> *J) try/catch: >> 1) - in the ERROR_TYPE:ERROR catch the throw: can be left out, and it >> means the same as catching a throw of type "Error".. nice short hand. >> There is also a 3rd parameter in the AST that is always a match all ( a >> bit like ERROR_TYPE:ERROR:_ ) does anybody know what this means? is there an >> extra option in a catch? >> >> ( maybe everybody knows these last few but just to be sure ) >> 2) if nothing matches in the catch statements the error propagates up as >> if there was no try catch at all, very useful and stops the need for >> re-throwing like other languages! >> 3) in the try Code of ... catch the "of" is optional & returns the CODE >> value if left out, also ( maybe v obvious) the code in the "of" section is >> not caught >> 4) the old, strange and broken "catch" requires wrapping in parens if you >> want its return value: >> Var = catch throw(100). seems to be a syntax error >> Var = (catch throw(100)). is fine >> also distinguishing between certain throws and an ordinary return can be >> impossible. >> >> *K) records >> ( this got too long so I made it a follow on email :-) basically I wish to >> write a (better) parse transform fix ) >> >> If after corrections/some extra suggestions someone wants to put this on >> their blog then feel free, I don't have one :-) >> James >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebegumisa@REDACTED Fri May 20 00:05:55 2011 From: ebegumisa@REDACTED (Edmond Begumisa) Date: Fri, 20 May 2011 08:05:55 +1000 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: Message-ID: As I child I asked my mathematician father: "Why is the number pad of a telephone in the flipped order from the number pad on a calculator/computer keyboard?" His answer: "That's just the way it is." Sometimes "that's just the way it is" is a perfectly sufficient and reasonable answer to both questions: why something is done a particular way; and why it shouldn't be changed. Mind you on the noob argument: when I first started learning Erlang (my first functional language -- I had tried Lisp and gave up), I found the current syntax a very good learning aid. To use Turner's original example... factorial(0) -> 1; factorial(N) when N > 0 -> N*factorial(N-1). I would read this as... "The factorial of 0 is 1; the factorial of N when N is greater than zero is N times the factorial of N - 1." Having the function name at the beginning of each clause helped me greatly to adapt to the declarative nature of Erlang. In contrast, I first struggled with multi-clause funs because my brain wanted so badly to use the anatomy of a function that I was so used to from imperative languages. So I'd argue that changing this might make code actually *harder* for noobs when they come across it. The function names reinforce the declarative nature of Erlang, me thinks. Besides, every programmer I know is a touch-typist -- it's not _that_ much work typing the function names :) - Edmond - >>>> > factorial >>>> > (1) -> 1; >>>> > (N) -> N*factorial(N-1). >>>> > >>>> > gives me a syntax error. I find the latter more readable than >>>> > >>>> > factorial(1) -> 1; >>>> > factorial(2) -> N*fact(N-1). > On Fri, 20 May 2011 03:19:11 +1000, Mike Oxford wrote: > Noting that I'm not against core language changes where critically > warranted, why is this one particular thing such an issue to you? > > Erlang is not an ivory-tower-on-a-hill-university-project. It's an > organically-grown beast that gets down in the trenches and brawls in the > mud. > If you don't like it, write it off as an "Erlang wart." Every language > has > them. If you don't like it then write your own, or your own parser. > > For what it's worth, some users (such as myself) actually PREFER it the > way > it is because it makes code-scanning easier from a visual standpoint. > Yes, I'm one of those people who will put "comment breaks" between > methods > in my code, too, regardless of language. > > And to reference your copy-paste-mutate argument....what do you think > we'll > be doing for every internal case-clause? Yes, that's right, > copy-paste-mutate the pattern matches except that you now have your > logical > branches at indent-level-1 with, potentially, the rest of your code that > doesn't deal with argument-specific code instead of at indent-level-0. > If > you need "common chunks of code" well, I'm pretty sure that's why we have > methods. To wit, write your "unified interface" and case it yourself > and > call the argument specific sub-method. > > My vote: keep it as it is. > > > > -mox > > > On Wed, May 18, 2011 at 9:39 PM, Michael Turner < > michael.eugene.turner@REDACTED> wrote: > >> Joe, with all due respect, I think you've misinterpreted DRY. It's not a >> matter of writing something again because you can't find where it's >> already >> implemented. In fact, the canonical example of DRY is to write something >> that works for one case, and then, rather than define it as a function, >> template or macro, and invoke it with varying parameters, instead >> copy-paste-mutate for each case. In fact, the most common violations of >> DRY >> are *precisely* when you know where the repeated code is, either because >> you've just found it or because you've just written it. >> >> "DRY says that every piece of system knowledge should have one >> authoritative, unambiguous representation." >> >> http://www.artima.com/intv/dry.html >> >> Erlang function definition syntax has two representations in the parser >> -- >> for no good reason I can see. Why? >> >> "Changing syntax is *incredibly difficult* project managers get >> apoplectic >> at the thought of retesting million lines of code -" >> >> No existing code will use the syntax I suggest. So how can any of it >> break? >> >> I have yet to get an answer: what could this proposed change possibly >> break, even *theoretically*? >> >> -michael turner >> >> On Thu, May 19, 2011 at 6:47 AM, Joe Armstrong wrote: >> >>> >>> >>> On Wed, May 18, 2011 at 5:29 PM, Parnell Springmeyer >>> wrote: >>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> Sorry, but Erlang doesn't *need* a better chance of survival. This >>>> language is not just growing, it's booming. Changing core language >>>> features that are solid, well thought out, and non-harmful (in other >>>> words, they are, FEATURES) to make it more "adoptable" is a lot like >>>> someone saying, "you have to quit that quirky smile so other people >>>> will >>>> like you more." >>>> >>> >>> Languages survive forever once they get to the point where >>> >>> 1) legacy applications in the language still earn money >>> 2) it costs more to convert to a new language than maintain the >>> existing app in the old language >>> >>> Erlang reached this point, many years ago. >>> >>> Right now Erlang companies have a commercial advantage >>> over non-erlang companies and so there is not much point in >>> trying to spread the language further - you just loose your commercial >>> advantage. >>> >>> /Joe >>> >>> >>>> >>>> Sometimes, yes, there are features in a language that could use >>>> refinement - but many times, in a mature language, the ratio between >>>> need and usefulness in refining a feature further, drops >>>> significantly. >>>> >>>> Instead of changing something that is solid, educate the people that >>>> have a hard time grasping it, build killer example applications that >>>> exhibit the quirky style and idioms to a T - people /will/ follow it, >>>> almost to a religious end. >>>> >>>> That's actually what I like about Erlang the most, the documentation >>>> has >>>> so many gems in it like the efficiency guide (where many common idioms >>>> are expressed with clear DO and DON'T DO examples) and style guide. >>>> >>>> RE: syntactic consistency: Erlang's syntax *IS* consistent - it's more >>>> consistent than many languages I've touched. >>>> >>>> Is Erlang easy for a Perl programmer? I bet not, and Perl's syntax is >>>> less consistent than Erlang's is in my opinion. The issue you are >>>> attempting to get at is (again) an educational and experience one, not >>>> something that is inherently wrong with the language or its expression >>>> itself. >>>> >>>> I'm actually baffled by the efforts people are putting into different >>>> Erlang VM frontends that look like Ruby or Python. Good on them for >>>> exercising the freedom of open source but /why/? Erlang's syntax is >>>> almost beautiful to me now after using it, it's so well suited for >>>> what >>>> Erlang is good at! >>>> >>>> Erlang isn't that great for general purpose programming - you use >>>> Python, Ruby, C, D, etc... for stuff like that. Erlang is great at >>>> fault >>>> tolerance, easy parallelism (which isn't easy!), and hot code >>>> loading. Features that are so difficult to do in the traditional >>>> imperative environment that (to date) I have not seen a single >>>> implementation of any one of those features that even approaches the >>>> completeness of Erlang's. >>>> >>>> Michael Turner writes: >>>> >>>> > Another objection raised against this syntax change is that all >>>> > functional languages violate DRY in this manner, so it's OK if >>>> Erlang >>>> > does it too. This is a Principle of Least Surprise argument, and not >>>> > bad as far as it goes. But how far does it go? >>>> > >>>> > Erlang will have a better chance of greater success and survival if >>>> you >>>> > consider your recruitment base to be the overwhelming majority of >>>> > programmers. And from what I can tell, >>>> > >>>> > http://www.langpop.com >>>> > >>>> > the overwhelming majority of programmers have no experience to speak >>>> > of, when it comes to functional programming languages. Appealing to >>>> the >>>> > "cross-training" benefit of coming from other FP languages seems >>>> like a >>>> > pretty weak argument. Especially since all I'm asking for here is >>>> > syntactic consistency *within* Erlang -- a PLoS argument in itself. >>>> > >>>> > Richard O'Keefe suggests that the syntactic consistency goal is >>>> better >>>> > met by allowing a kind of limited-scope special-case fun name, >>>> > permitting, e.g. >>>> > >>>> > Fact = fun F(0) -> 1; F(N) -> N*F(N-1) end. >>>> > >>>> > I could get behind that too, but I don't follow his reasoning from >>>> > syntactic consistency, which is apparently that an unnamed fun has a >>>> > name, it's just the degenerate case of a name. It's really there. >>>> We >>>> > just can't see it. Hm, really? If that were true in Erlang as it >>>> > stands, shouldn't I be able to write it this way? >>>> > >>>> > Fact = fun (0) -> 1; (N) -> N*''(N-1) end. >>>> > >>>> > Looks like it's not quite that simple. It compiles, but it doesn't >>>> know >>>> > what module to look in for '', when it comes time to execute. In the >>>> > shell, I get an error indicating that it tried to resolve ''/1 as a >>>> > shell command. Even if I put it in a .erl file and compile it, >>>> there's >>>> > no obvious way to tell the compiler what module to look in. >>>> ?MODULE:'' >>>> > doesn't work. Nor does '':'', which I tried just for the hell of it. >>>> > >>>> > What Richard's suggesting appears to require a rigorous re-think of >>>> how >>>> > scopes are defined in Erlang. What I'm suggesting amounts to simply >>>> > asking the compiler to do some of your tedious keying for you. >>>> > >>>> > -michael turner >>>> > >>>> > >>>> > On Wed, May 18, 2011 at 6:16 PM, Michael Turner < >>>> > michael.eugene.turner@REDACTED> wrote: >>>> > >>>> > I can say >>>> > >>>> > fun (1)->2; >>>> > (2)->1 >>>> > end >>>> > >>>> > but, oddly, I can't define a named function in the analogous >>>> way, >>>> > e.g.: >>>> > >>>> > factorial >>>> > (1) -> 1; >>>> > (N) -> N*factorial(N-1). >>>> > >>>> > gives me a syntax error. I find the latter more readable than >>>> > >>>> > factorial(1) -> 1; >>>> > factorial(2) -> N*fact(N-1). >>>> > >>>> > It's also less to type and to read, which is consistent with the >>>> > DRY principle ("Don't Repeat Yourself"). And it lends itself to >>>> > reading a function definition as a set of cases. I think for >>>> Erlang >>>> > newbies, it should therefore would be preferred: it helps >>>> > underscore the pattern-matching style of Erlang function >>>> > invocation. >>>> > >>>> > It also looks a *little* bit more like the mathematical >>>> convention >>>> > for defining these sorts of functions, where you have "f(x) = ", >>>> > centered vertically to the left of a big left "{" that (left-) >>>> > encloses the list of expression/parameter-condition pairs in a >>>> > two-column format, e.g., >>>> > >>>> > http://cnx.org/content/m29517/latest/Picture%2047.png >>>> > >>>> > So there's a (weak) argument from the Principle of Least >>>> Surprise >>>> > here as well. >>>> > >>>> > It seems to me that, if anything, this requires only a >>>> > *simplification* of the Erlang parser. That leaves only one >>>> obvious >>>> > objection: would any existing code break if Erlang syntax were >>>> > altered to allow this? >>>> > >>>> > -michael turner >>>> > >>>> > _______________________________________________ >>>> > erlang-questions mailing list >>>> > erlang-questions@REDACTED >>>> > http://erlang.org/mailman/listinfo/erlang-questions >>>> >>>> - -- >>>> Parnell "ixmatus" Springmeyer (http://ixmat.us) >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG/MacGPG2 v2.0.17 (Darwin) >>>> Comment: GPGTools - http://gpgtools.org >>>> >>>> iQEcBAEBAgAGBQJN0+XsAAoJEPvtlbpI1POLEXEIAJrjAGVTkveBi5/akYNMjBEX >>>> 8wI9twatnXh8sfg2ohGKr3P1hj4jTr9ARrG5wiB9OCArRkBymnjFeY5g2dkBDOhN >>>> aN722l+yDPpUewAM58m0dDoDHjrHXvxF1MJejQJGhQ+Nr9fM+7G+4QIrCN9RvX1S >>>> QTAS+OqOnl8lsS98yvUiXXLB5ehdHcR46Ix6Sq7UwSvqaOKZMoPrzkTtW3VyS5kf >>>> i/uGbPZ1I3KQJYRShk2QlLis/tpXGtLDnYc1E5uADqeClDXy5Au6LWpNqUjNIiWw >>>> h8I2emcBq5Ur7nivNUYgnVMjg+0qTkQOtttPpOJ25xIYv07L+eMfXneb5nRx4hc= >>>> =GGPU >>>> -----END PGP SIGNATURE----- >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>> >>> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From jameschurchman@REDACTED Fri May 20 00:44:43 2011 From: jameschurchman@REDACTED (James Churchman) Date: Thu, 19 May 2011 23:44:43 +0100 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: Message-ID: winner for the most nit-pickey thread ever also : >Me, I'd like to say > > L = [{foo, fun(X,Y) -> ... end}, {bar, fun(X) -> ... end}] > then have couple of new bifs Mod = list_to_mod(L) to compose a module from a load of funs and mod_to_list to do the inverse. should be possible by generating a bit of ast and would indeed be a cool addition to the runtime :-) On 19 May 2011 23:05, Edmond Begumisa wrote: > As I child I asked my mathematician father: > > "Why is the number pad of a telephone in the flipped order from the number > pad on a calculator/computer keyboard?" > > His answer: "That's just the way it is." > > Sometimes "that's just the way it is" is a perfectly sufficient and > reasonable answer to both questions: why something is done a particular way; > and why it shouldn't be changed. > > Mind you on the noob argument: when I first started learning Erlang (my > first functional language -- I had tried Lisp and gave up), I found the > current syntax a very good learning aid. To use Turner's original example... > > factorial(0) -> 1; > factorial(N) when N > 0 -> N*factorial(N-1). > > I would read this as... > > "The factorial of 0 is 1; the factorial of N when N is greater than zero is > N times the factorial of N - 1." > > Having the function name at the beginning of each clause helped me greatly > to adapt to the declarative nature of Erlang. In contrast, I first struggled > with multi-clause funs because my brain wanted so badly to use the anatomy > of a function that I was so used to from imperative languages. > > So I'd argue that changing this might make code actually *harder* for noobs > when they come across it. The function names reinforce the declarative > nature of Erlang, me thinks. > > Besides, every programmer I know is a touch-typist -- it's not _that_ much > work typing the function names :) > > - Edmond - > > > > > factorial >>>>> > (1) -> 1; >>>>> > (N) -> N*factorial(N-1). >>>>> > >>>>> > gives me a syntax error. I find the latter more readable than >>>>> > >>>>> > factorial(1) -> 1; >>>>> > factorial(2) -> N*fact(N-1). >>>>> >>>> >> > > > > > On Fri, 20 May 2011 03:19:11 +1000, Mike Oxford wrote: > > Noting that I'm not against core language changes where critically >> warranted, why is this one particular thing such an issue to you? >> >> Erlang is not an ivory-tower-on-a-hill-university-project. It's an >> organically-grown beast that gets down in the trenches and brawls in the >> mud. >> If you don't like it, write it off as an "Erlang wart." Every language >> has >> them. If you don't like it then write your own, or your own parser. >> >> For what it's worth, some users (such as myself) actually PREFER it the >> way >> it is because it makes code-scanning easier from a visual standpoint. >> Yes, I'm one of those people who will put "comment breaks" between methods >> in my code, too, regardless of language. >> >> And to reference your copy-paste-mutate argument....what do you think >> we'll >> be doing for every internal case-clause? Yes, that's right, >> copy-paste-mutate the pattern matches except that you now have your >> logical >> branches at indent-level-1 with, potentially, the rest of your code that >> doesn't deal with argument-specific code instead of at indent-level-0. If >> you need "common chunks of code" well, I'm pretty sure that's why we have >> methods. To wit, write your "unified interface" and case it yourself and >> call the argument specific sub-method. >> >> My vote: keep it as it is. >> >> >> >> -mox >> >> >> On Wed, May 18, 2011 at 9:39 PM, Michael Turner < >> michael.eugene.turner@REDACTED> wrote: >> >> Joe, with all due respect, I think you've misinterpreted DRY. It's not a >>> matter of writing something again because you can't find where it's >>> already >>> implemented. In fact, the canonical example of DRY is to write something >>> that works for one case, and then, rather than define it as a function, >>> template or macro, and invoke it with varying parameters, instead >>> copy-paste-mutate for each case. In fact, the most common violations of >>> DRY >>> are *precisely* when you know where the repeated code is, either because >>> you've just found it or because you've just written it. >>> >>> "DRY says that every piece of system knowledge should have one >>> authoritative, unambiguous representation." >>> >>> http://www.artima.com/intv/dry.html >>> >>> Erlang function definition syntax has two representations in the parser >>> -- >>> for no good reason I can see. Why? >>> >>> "Changing syntax is *incredibly difficult* project managers get >>> apoplectic >>> at the thought of retesting million lines of code -" >>> >>> No existing code will use the syntax I suggest. So how can any of it >>> break? >>> >>> I have yet to get an answer: what could this proposed change possibly >>> break, even *theoretically*? >>> >>> -michael turner >>> >>> On Thu, May 19, 2011 at 6:47 AM, Joe Armstrong wrote: >>> >>> >>>> >>>> On Wed, May 18, 2011 at 5:29 PM, Parnell Springmeyer >>> >wrote: >>>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA1 >>>>> >>>>> Sorry, but Erlang doesn't *need* a better chance of survival. This >>>>> language is not just growing, it's booming. Changing core language >>>>> features that are solid, well thought out, and non-harmful (in other >>>>> words, they are, FEATURES) to make it more "adoptable" is a lot like >>>>> someone saying, "you have to quit that quirky smile so other people >>>>> will >>>>> like you more." >>>>> >>>>> >>>> Languages survive forever once they get to the point where >>>> >>>> 1) legacy applications in the language still earn money >>>> 2) it costs more to convert to a new language than maintain the >>>> existing app in the old language >>>> >>>> Erlang reached this point, many years ago. >>>> >>>> Right now Erlang companies have a commercial advantage >>>> over non-erlang companies and so there is not much point in >>>> trying to spread the language further - you just loose your commercial >>>> advantage. >>>> >>>> /Joe >>>> >>>> >>>> >>>>> Sometimes, yes, there are features in a language that could use >>>>> refinement - but many times, in a mature language, the ratio between >>>>> need and usefulness in refining a feature further, drops significantly. >>>>> >>>>> Instead of changing something that is solid, educate the people that >>>>> have a hard time grasping it, build killer example applications that >>>>> exhibit the quirky style and idioms to a T - people /will/ follow it, >>>>> almost to a religious end. >>>>> >>>>> That's actually what I like about Erlang the most, the documentation >>>>> has >>>>> so many gems in it like the efficiency guide (where many common idioms >>>>> are expressed with clear DO and DON'T DO examples) and style guide. >>>>> >>>>> RE: syntactic consistency: Erlang's syntax *IS* consistent - it's more >>>>> consistent than many languages I've touched. >>>>> >>>>> Is Erlang easy for a Perl programmer? I bet not, and Perl's syntax is >>>>> less consistent than Erlang's is in my opinion. The issue you are >>>>> attempting to get at is (again) an educational and experience one, not >>>>> something that is inherently wrong with the language or its expression >>>>> itself. >>>>> >>>>> I'm actually baffled by the efforts people are putting into different >>>>> Erlang VM frontends that look like Ruby or Python. Good on them for >>>>> exercising the freedom of open source but /why/? Erlang's syntax is >>>>> almost beautiful to me now after using it, it's so well suited for what >>>>> Erlang is good at! >>>>> >>>>> Erlang isn't that great for general purpose programming - you use >>>>> Python, Ruby, C, D, etc... for stuff like that. Erlang is great at >>>>> fault >>>>> tolerance, easy parallelism (which isn't easy!), and hot code >>>>> loading. Features that are so difficult to do in the traditional >>>>> imperative environment that (to date) I have not seen a single >>>>> implementation of any one of those features that even approaches the >>>>> completeness of Erlang's. >>>>> >>>>> Michael Turner writes: >>>>> >>>>> > Another objection raised against this syntax change is that all >>>>> > functional languages violate DRY in this manner, so it's OK if Erlang >>>>> > does it too. This is a Principle of Least Surprise argument, and not >>>>> > bad as far as it goes. But how far does it go? >>>>> > >>>>> > Erlang will have a better chance of greater success and survival if >>>>> you >>>>> > consider your recruitment base to be the overwhelming majority of >>>>> > programmers. And from what I can tell, >>>>> > >>>>> > http://www.langpop.com >>>>> > >>>>> > the overwhelming majority of programmers have no experience to speak >>>>> > of, when it comes to functional programming languages. Appealing to >>>>> the >>>>> > "cross-training" benefit of coming from other FP languages seems like >>>>> a >>>>> > pretty weak argument. Especially since all I'm asking for here is >>>>> > syntactic consistency *within* Erlang -- a PLoS argument in itself. >>>>> > >>>>> > Richard O'Keefe suggests that the syntactic consistency goal is >>>>> better >>>>> > met by allowing a kind of limited-scope special-case fun name, >>>>> > permitting, e.g. >>>>> > >>>>> > Fact = fun F(0) -> 1; F(N) -> N*F(N-1) end. >>>>> > >>>>> > I could get behind that too, but I don't follow his reasoning from >>>>> > syntactic consistency, which is apparently that an unnamed fun has a >>>>> > name, it's just the degenerate case of a name. It's really there. We >>>>> > just can't see it. Hm, really? If that were true in Erlang as it >>>>> > stands, shouldn't I be able to write it this way? >>>>> > >>>>> > Fact = fun (0) -> 1; (N) -> N*''(N-1) end. >>>>> > >>>>> > Looks like it's not quite that simple. It compiles, but it doesn't >>>>> know >>>>> > what module to look in for '', when it comes time to execute. In the >>>>> > shell, I get an error indicating that it tried to resolve ''/1 as a >>>>> > shell command. Even if I put it in a .erl file and compile it, >>>>> there's >>>>> > no obvious way to tell the compiler what module to look in. >>>>> ?MODULE:'' >>>>> > doesn't work. Nor does '':'', which I tried just for the hell of it. >>>>> > >>>>> > What Richard's suggesting appears to require a rigorous re-think of >>>>> how >>>>> > scopes are defined in Erlang. What I'm suggesting amounts to simply >>>>> > asking the compiler to do some of your tedious keying for you. >>>>> > >>>>> > -michael turner >>>>> > >>>>> > >>>>> > On Wed, May 18, 2011 at 6:16 PM, Michael Turner < >>>>> > michael.eugene.turner@REDACTED> wrote: >>>>> > >>>>> > I can say >>>>> > >>>>> > fun (1)->2; >>>>> > (2)->1 >>>>> > end >>>>> > >>>>> > but, oddly, I can't define a named function in the analogous way, >>>>> > e.g.: >>>>> > >>>>> > factorial >>>>> > (1) -> 1; >>>>> > (N) -> N*factorial(N-1). >>>>> > >>>>> > gives me a syntax error. I find the latter more readable than >>>>> > >>>>> > factorial(1) -> 1; >>>>> > factorial(2) -> N*fact(N-1). >>>>> > >>>>> > It's also less to type and to read, which is consistent with the >>>>> > DRY principle ("Don't Repeat Yourself"). And it lends itself to >>>>> > reading a function definition as a set of cases. I think for >>>>> Erlang >>>>> > newbies, it should therefore would be preferred: it helps >>>>> > underscore the pattern-matching style of Erlang function >>>>> > invocation. >>>>> > >>>>> > It also looks a *little* bit more like the mathematical >>>>> convention >>>>> > for defining these sorts of functions, where you have "f(x) = ", >>>>> > centered vertically to the left of a big left "{" that (left-) >>>>> > encloses the list of expression/parameter-condition pairs in a >>>>> > two-column format, e.g., >>>>> > >>>>> > http://cnx.org/content/m29517/latest/Picture%2047.png >>>>> > >>>>> > So there's a (weak) argument from the Principle of Least Surprise >>>>> > here as well. >>>>> > >>>>> > It seems to me that, if anything, this requires only a >>>>> > *simplification* of the Erlang parser. That leaves only one >>>>> obvious >>>>> > objection: would any existing code break if Erlang syntax were >>>>> > altered to allow this? >>>>> > >>>>> > -michael turner >>>>> > >>>>> > _______________________________________________ >>>>> > erlang-questions mailing list >>>>> > erlang-questions@REDACTED >>>>> > http://erlang.org/mailman/listinfo/erlang-questions >>>>> >>>>> - -- >>>>> Parnell "ixmatus" Springmeyer (http://ixmat.us) >>>>> -----BEGIN PGP SIGNATURE----- >>>>> Version: GnuPG/MacGPG2 v2.0.17 (Darwin) >>>>> Comment: GPGTools - http://gpgtools.org >>>>> >>>>> iQEcBAEBAgAGBQJN0+XsAAoJEPvtlbpI1POLEXEIAJrjAGVTkveBi5/akYNMjBEX >>>>> 8wI9twatnXh8sfg2ohGKr3P1hj4jTr9ARrG5wiB9OCArRkBymnjFeY5g2dkBDOhN >>>>> aN722l+yDPpUewAM58m0dDoDHjrHXvxF1MJejQJGhQ+Nr9fM+7G+4QIrCN9RvX1S >>>>> QTAS+OqOnl8lsS98yvUiXXLB5ehdHcR46Ix6Sq7UwSvqaOKZMoPrzkTtW3VyS5kf >>>>> i/uGbPZ1I3KQJYRShk2QlLis/tpXGtLDnYc1E5uADqeClDXy5Au6LWpNqUjNIiWw >>>>> h8I2emcBq5Ur7nivNUYgnVMjg+0qTkQOtttPpOJ25xIYv07L+eMfXneb5nRx4hc= >>>>> =GGPU >>>>> -----END PGP SIGNATURE----- >>>>> _______________________________________________ >>>>> erlang-questions mailing list >>>>> erlang-questions@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>>> >>>>> >>>> >>>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >>> > > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebegumisa@REDACTED Fri May 20 00:49:51 2011 From: ebegumisa@REDACTED (Edmond Begumisa) Date: Fri, 20 May 2011 08:49:51 +1000 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: <7418517D-4A84-4F44-94E8-B15045F5DAC0@erlang-solutions.com> References: <1930B4D4-54DD-4F80-ACDE-BBE983315E64@hates.ms> <20110519093746.GB27904@erix.ericsson.se> <7418517D-4A84-4F44-94E8-B15045F5DAC0@erlang-solutions.com> Message-ID: > People already complain that Erlang's syntax is too ugly or complex; I've always found this complaint to be rather quibble. Programmers have brains that are extremely well adjusted to parsing new syntax. This is one thing all programmers are inherently good at. Yet when asked to put this skill towards learning a new language, they complain. "No" they say, "give me a syntax I'm already familiar with. Why are you trying to be different?" they ask. I learned Erlang by reading Joe's book. Within half an hour I wasn't seeing the syntax anymore. My brain, quickly made the necessary mental mappings. I strongly believe this to be the case with all programmers when encountering an unfamiliar syntax -- rapid adjustment with relatively little effort. Other professions are not so lucky. I once witnessed two non-programmers trying to learn HTML at the same time. One a medical doctor, the other a graphic designer. Both got the concepts down very quickly (links, images, tables, etc), but both really struggled with syntax. "How can one possibly read this?" they kept asking. Yet most programmers learn HTML/XML syntax in a matter of minutes while watching TV. Gut give them Erlang and they groan and complain loudly. IMHO, complaints about Erlang's syntax being "too weird" are completely unwarranted. A programmer could learn a language written using Klingon symbols in a unbelievably short period of time. Just look at all those non-English speakers who program in languages heavily biased towards English. And many of them come from languages using non-latin scripts!!! - Edmond - PS: The exception is Lisp. All those parentheses are just obfuscating :) On Thu, 19 May 2011 21:41:50 +1000, Fr?d?ric Trottier-H?bert wrote: > I would rather have one clear but slightly verbose way of doing things > rather than two potential ways to do the same thing in slightly > different manners prompting religious wars to get the same result I > already have. > > The idea to revisit the syntax isn't bad in itself, but looking at the > examples Steve Davis provided, I can only see your concept being useful > for very short functions. > > When it comes to learning Erlang, I can tell you that in my experience, > new users struggle a lot more with clause separators (;), expression > separators (,), form terminators (.), records, 'if' or funs (in concept) > than they do with function syntax. They do not seem to see the current > way to write function heads as problematic. Then, all Erlang users are > also used to it. > > Adding more ways to do things that currently have a single way to be > done is a net loss in my opinion. People already complain that Erlang's > syntax is too ugly or complex; I do not think that adding more syntax is > the way to solve that. It would not benefit new users and it would not > benefit the majority of all users, only increase the ways they can read > code and get confused. > > In the other thread, someone called it 'syntactic salt', and I think > this is a good way to describe how things are right now. It's not a bad > thing in my opinion. > > On 2011-05-19, at 06:47 AM, Michael Turner wrote: > >> "But how interesting is whether existing code would break or not?" >> >> Not very. I mean, who uses Erlang for anything important? Hardly >> anybody, right? >> >> [/sarcasm] >> >> "It would, as others have pointed out, also be much harder to jump into >> a module and _know_ what the clause does since the function's name can >> be pages away." >> >> It would only be harder ("much"??) if you *chose*, in such cases, to >> use the syntax I propose to bring over from multi-clause funs. In the >> case you bring up, it might be wiser not to. And what I propose clearly >> allows everyone to continue with the present syntax. So your argument >> for readability in this case comes down to "somebody might not use this >> language feature wisely." (*facepalm*). >> >> -michael turner >> _______ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > -- > Fred H?bert > http://www.erlang-solutions.com -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From pablo.platt@REDACTED Fri May 20 01:19:46 2011 From: pablo.platt@REDACTED (Pablo Platt) Date: Thu, 19 May 2011 16:19:46 -0700 (PDT) Subject: [erlang-questions] multiple httpc requests with the default profile which work like multiple profiles Message-ID: <377813.37445.qm@web112613.mail.gq1.yahoo.com> I'm using httpc to load test a Comet long-polling server. Each client is simulated with a gen_server that makes an http request using httpc. The first request the client send is a sync request and subsequent requests are async. On the server side, in the receive of the pid that has the socket, I'm getting a message from a request sent by another client: {tcp,#Port<0.4011>,"GET /test/?user=12 HTTP/1.1\r\nHost: host.test:8000\r\nContent-Length: 0\r\n\r\n"} The above happens when all clients are using the default httpc profile. When I'm using a separate profile for each client, I don't get the above message. The problem is that I'm exceeding the max allowed ETS tables. Does each profile use a separate ETS table? (why?) Is it a known behavior that a socket get a new http request before responding to the first one? Is it related to pipelining? What setting do I need for the default profile to make it work like a separate profile for each client? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From fred.hebert@REDACTED Fri May 20 01:20:52 2011 From: fred.hebert@REDACTED (=?iso-8859-1?Q?Fr=E9d=E9ric_Trottier-H=E9bert?=) Date: Thu, 19 May 2011 19:20:52 -0400 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: <1930B4D4-54DD-4F80-ACDE-BBE983315E64@hates.ms> <20110519093746.GB27904@erix.ericsson.se> <7418517D-4A84-4F44-94E8-B15045F5DAC0@erlang-solutions.com> Message-ID: <1DB4D10E-B83D-4E69-8888-18CE552DC785@erlang-solutions.com> I don't agree with complaints either -- I have no issue with Erlang's syntax, lisp/scheme/racket's syntax or any other language. The reality, however, is that while programmers can pick up Erlang's syntax quickly, there's still an initial struggle to break what has been committed to muscle memory by many of the people I have taught it to. The syntax might be the scapegoat of the difficulty in learning foreign concepts like functional paradigms, concurrent ideas or pattern matching, but in any case, it is a hurdle that newcomers have to step over. It's not because they can beat challenges that we have to make it harder on purpose by introducing new elements like the alternative function syntax. -- Fred H?bert http://www.erlang-solutions.com On 2011-05-19, at 18:49 PM, Edmond Begumisa wrote: >> People already complain that Erlang's syntax is too ugly or complex; > > I've always found this complaint to be rather quibble. > > Programmers have brains that are extremely well adjusted to parsing new syntax. This is one thing all programmers are inherently good at. Yet when asked to put this skill towards learning a new language, they complain. "No" they say, "give me a syntax I'm already familiar with. Why are you trying to be different?" they ask. > > I learned Erlang by reading Joe's book. Within half an hour I wasn't seeing the syntax anymore. My brain, quickly made the necessary mental mappings. I strongly believe this to be the case with all programmers when encountering an unfamiliar syntax -- rapid adjustment with relatively little effort. > > Other professions are not so lucky. I once witnessed two non-programmers trying to learn HTML at the same time. One a medical doctor, the other a graphic designer. Both got the concepts down very quickly (links, images, tables, etc), but both really struggled with syntax. "How can one possibly read this?" they kept asking. > > Yet most programmers learn HTML/XML syntax in a matter of minutes while watching TV. Gut give them Erlang and they groan and complain loudly. > > IMHO, complaints about Erlang's syntax being "too weird" are completely unwarranted. A programmer could learn a language written using Klingon symbols in a unbelievably short period of time. Just look at all those non-English speakers who program in languages heavily biased towards English. And many of them come from languages using non-latin scripts!!! > > - Edmond - > > PS: The exception is Lisp. All those parentheses are just obfuscating :) > > > > On Thu, 19 May 2011 21:41:50 +1000, Fr?d?ric Trottier-H?bert wrote: > >> I would rather have one clear but slightly verbose way of doing things rather than two potential ways to do the same thing in slightly different manners prompting religious wars to get the same result I already have. >> >> The idea to revisit the syntax isn't bad in itself, but looking at the examples Steve Davis provided, I can only see your concept being useful for very short functions. >> >> When it comes to learning Erlang, I can tell you that in my experience, new users struggle a lot more with clause separators (;), expression separators (,), form terminators (.), records, 'if' or funs (in concept) than they do with function syntax. They do not seem to see the current way to write function heads as problematic. Then, all Erlang users are also used to it. >> >> Adding more ways to do things that currently have a single way to be done is a net loss in my opinion. People already complain that Erlang's syntax is too ugly or complex; I do not think that adding more syntax is the way to solve that. It would not benefit new users and it would not benefit the majority of all users, only increase the ways they can read code and get confused. >> >> In the other thread, someone called it 'syntactic salt', and I think this is a good way to describe how things are right now. It's not a bad thing in my opinion. >> >> On 2011-05-19, at 06:47 AM, Michael Turner wrote: >> >>> "But how interesting is whether existing code would break or not?" >>> >>> Not very. I mean, who uses Erlang for anything important? Hardly anybody, right? >>> >>> [/sarcasm] >>> >>> "It would, as others have pointed out, also be much harder to jump into a module and _know_ what the clause does since the function's name can be pages away." >>> >>> It would only be harder ("much"??) if you *chose*, in such cases, to use the syntax I propose to bring over from multi-clause funs. In the case you bring up, it might be wiser not to. And what I propose clearly allows everyone to continue with the present syntax. So your argument for readability in this case comes down to "somebody might not use this language feature wisely." (*facepalm*). >>> >>> -michael turner >>> _______ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> >> -- >> Fred H?bert >> http://www.erlang-solutions.com > > > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From ebegumisa@REDACTED Fri May 20 01:57:13 2011 From: ebegumisa@REDACTED (Edmond Begumisa) Date: Fri, 20 May 2011 09:57:13 +1000 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: <1DB4D10E-B83D-4E69-8888-18CE552DC785@erlang-solutions.com> References: <1930B4D4-54DD-4F80-ACDE-BBE983315E64@hates.ms> <20110519093746.GB27904@erix.ericsson.se> <7418517D-4A84-4F44-94E8-B15045F5DAC0@erlang-solutions.com> <1DB4D10E-B83D-4E69-8888-18CE552DC785@erlang-solutions.com> Message-ID: On Fri, 20 May 2011 09:20:52 +1000, Fr?d?ric Trottier-H?bert wrote: > I don't agree with complaints either -- I have no issue with Erlang's > syntax, lisp/scheme/racket's syntax or any other language. The reality, > however, is that while programmers can pick up Erlang's syntax quickly, > there's still an initial struggle to break what has been committed to > muscle memory by many of the people I have taught it to. > > The syntax might be the scapegoat of the difficulty in learning foreign > concepts like functional paradigms, concurrent ideas or pattern matching, I have a more cynical view: I think programmers just like to whinge. On average, more than other people. Syntax just happens to be the first thing you can complain about when someone says to you "learn Erlang." (not referring to Mr Turner or his proposal here but rather the usual superficial general complaints about Erlang.) > but in any case, it is a hurdle that newcomers have to step over. It's > not because they can beat challenges that we have to make it harder on > purpose by introducing new elements like the alternative function syntax. > Oh, I certainly wasn't arguing for this change. I personally don't see the added benefit (but I haven't been using Erlang that long, so I'll defer the opinions of the more experienced.) The syntax argument against Erlang (and python, and C++, and BASIC, and ...) has always really bugged me, that's all. - Edmond - > -- > Fred H?bert > http://www.erlang-solutions.com > > > > On 2011-05-19, at 18:49 PM, Edmond Begumisa wrote: > >>> People already complain that Erlang's syntax is too ugly or complex; >> >> I've always found this complaint to be rather quibble. >> >> Programmers have brains that are extremely well adjusted to parsing new >> syntax. This is one thing all programmers are inherently good at. Yet >> when asked to put this skill towards learning a new language, they >> complain. "No" they say, "give me a syntax I'm already familiar with. >> Why are you trying to be different?" they ask. >> >> I learned Erlang by reading Joe's book. Within half an hour I wasn't >> seeing the syntax anymore. My brain, quickly made the necessary mental >> mappings. I strongly believe this to be the case with all programmers >> when encountering an unfamiliar syntax -- rapid adjustment with >> relatively little effort. >> >> Other professions are not so lucky. I once witnessed two >> non-programmers trying to learn HTML at the same time. One a medical >> doctor, the other a graphic designer. Both got the concepts down very >> quickly (links, images, tables, etc), but both really struggled with >> syntax. "How can one possibly read this?" they kept asking. >> >> Yet most programmers learn HTML/XML syntax in a matter of minutes while >> watching TV. Gut give them Erlang and they groan and complain loudly. >> >> IMHO, complaints about Erlang's syntax being "too weird" are completely >> unwarranted. A programmer could learn a language written using Klingon >> symbols in a unbelievably short period of time. Just look at all those >> non-English speakers who program in languages heavily biased towards >> English. And many of them come from languages using non-latin scripts!!! >> >> - Edmond - >> >> PS: The exception is Lisp. All those parentheses are just obfuscating :) >> >> >> >> On Thu, 19 May 2011 21:41:50 +1000, Fr?d?ric Trottier-H?bert >> wrote: >> >>> I would rather have one clear but slightly verbose way of doing things >>> rather than two potential ways to do the same thing in slightly >>> different manners prompting religious wars to get the same result I >>> already have. >>> >>> The idea to revisit the syntax isn't bad in itself, but looking at the >>> examples Steve Davis provided, I can only see your concept being >>> useful for very short functions. >>> >>> When it comes to learning Erlang, I can tell you that in my >>> experience, new users struggle a lot more with clause separators (;), >>> expression separators (,), form terminators (.), records, 'if' or funs >>> (in concept) than they do with function syntax. They do not seem to >>> see the current way to write function heads as problematic. Then, all >>> Erlang users are also used to it. >>> >>> Adding more ways to do things that currently have a single way to be >>> done is a net loss in my opinion. People already complain that >>> Erlang's syntax is too ugly or complex; I do not think that adding >>> more syntax is the way to solve that. It would not benefit new users >>> and it would not benefit the majority of all users, only increase the >>> ways they can read code and get confused. >>> >>> In the other thread, someone called it 'syntactic salt', and I think >>> this is a good way to describe how things are right now. It's not a >>> bad thing in my opinion. >>> >>> On 2011-05-19, at 06:47 AM, Michael Turner wrote: >>> >>>> "But how interesting is whether existing code would break or not?" >>>> >>>> Not very. I mean, who uses Erlang for anything important? Hardly >>>> anybody, right? >>>> >>>> [/sarcasm] >>>> >>>> "It would, as others have pointed out, also be much harder to jump >>>> into a module and _know_ what the clause does since the function's >>>> name can be pages away." >>>> >>>> It would only be harder ("much"??) if you *chose*, in such cases, to >>>> use the syntax I propose to bring over from multi-clause funs. In the >>>> case you bring up, it might be wiser not to. And what I propose >>>> clearly allows everyone to continue with the present syntax. So your >>>> argument for readability in this case comes down to "somebody might >>>> not use this language feature wisely." (*facepalm*). >>>> >>>> -michael turner >>>> _______ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> -- >>> Fred H?bert >>> http://www.erlang-solutions.com >> >> >> -- >> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ > -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From overminddl1@REDACTED Fri May 20 02:01:31 2011 From: overminddl1@REDACTED (OvermindDL1) Date: Thu, 19 May 2011 18:01:31 -0600 Subject: [erlang-questions] 'reply-to' header in this mailing list In-Reply-To: <20110519165711.GQ7320@aluminum.local> References: <688144131.198481305727593991.JavaMail.root@zimbra> <600128661.198501305727597470.JavaMail.root@zimbra> <016d01cc1642$bc4dce10$34e96a30$@com> <20110519165711.GQ7320@aluminum.local> Message-ID: On May 19, 2011 10:57 AM, "Vance Shipley" wrote: > > On Thu, May 19, 2011 at 11:35:14AM -0500, David Mercer wrote: > } Can someone please elucidate the distinction between a mailing > } list and a forum? > > I have come to the conclusion that what is beneath these sort > of debates amounts to a generational gap. Those who grew up > with a mouse in their hands have different expectations than > those of us who grew up with our hands planted on the keyboard > looking at a command prompt. As one of the later my view is > that the distinction is: > > mailing list: push > forum: pull > > -- > -Vance > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions Why can it not just be configurable on a person by person basis by editing their own user preferences on the mailing list server? Certainly the mailing list software is not so poorly designed so as to require such a person specific option to be set only globally. ;-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan@REDACTED Fri May 20 02:57:10 2011 From: dan@REDACTED (Daniel Dormont) Date: Thu, 19 May 2011 20:57:10 -0400 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: <1DB4D10E-B83D-4E69-8888-18CE552DC785@erlang-solutions.com> References: <1930B4D4-54DD-4F80-ACDE-BBE983315E64@hates.ms> <20110519093746.GB27904@erix.ericsson.se> <7418517D-4A84-4F44-94E8-B15045F5DAC0@erlang-solutions.com> <1DB4D10E-B83D-4E69-8888-18CE552DC785@erlang-solutions.com> Message-ID: Speaking as a relative newb with experience in other languages, I agree. Perhaps my experience is unusual (though honestly, I don't think so) in that I've spent some quality time with Haskell and Standard ML before coming to Erlang, but this particular feature makes perfect sense to me in its current form. What I'd love is to have this in nested functions too. I don't care much care about syntactic consistency for its own sake (heck, Perl is one of my favorite languages, what does that tell you) so that's not my motivation; what excites me is being able to have recursive closures. dan 2011/5/19 Fr?d?ric Trottier-H?bert > I don't agree with complaints either -- I have no issue with Erlang's > syntax, lisp/scheme/racket's syntax or any other language. The reality, > however, is that while programmers can pick up Erlang's syntax quickly, > there's still an initial struggle to break what has been committed to muscle > memory by many of the people I have taught it to. > > The syntax might be the scapegoat of the difficulty in learning foreign > concepts like functional paradigms, concurrent ideas or pattern matching, > but in any case, it is a hurdle that newcomers have to step over. It's not > because they can beat challenges that we have to make it harder on purpose > by introducing new elements like the alternative function syntax. > > -- > Fred H?bert > http://www.erlang-solutions.com > > > > On 2011-05-19, at 18:49 PM, Edmond Begumisa wrote: > > >> People already complain that Erlang's syntax is too ugly or complex; > > > > I've always found this complaint to be rather quibble. > > > > Programmers have brains that are extremely well adjusted to parsing new > syntax. This is one thing all programmers are inherently good at. Yet when > asked to put this skill towards learning a new language, they complain. "No" > they say, "give me a syntax I'm already familiar with. Why are you trying to > be different?" they ask. > > > > I learned Erlang by reading Joe's book. Within half an hour I wasn't > seeing the syntax anymore. My brain, quickly made the necessary mental > mappings. I strongly believe this to be the case with all programmers when > encountering an unfamiliar syntax -- rapid adjustment with relatively little > effort. > > > > Other professions are not so lucky. I once witnessed two non-programmers > trying to learn HTML at the same time. One a medical doctor, the other a > graphic designer. Both got the concepts down very quickly (links, images, > tables, etc), but both really struggled with syntax. "How can one possibly > read this?" they kept asking. > > > > Yet most programmers learn HTML/XML syntax in a matter of minutes while > watching TV. Gut give them Erlang and they groan and complain loudly. > > > > IMHO, complaints about Erlang's syntax being "too weird" are completely > unwarranted. A programmer could learn a language written using Klingon > symbols in a unbelievably short period of time. Just look at all those > non-English speakers who program in languages heavily biased towards > English. And many of them come from languages using non-latin scripts!!! > > > > - Edmond - > > > > PS: The exception is Lisp. All those parentheses are just obfuscating :) > > > > > > > > On Thu, 19 May 2011 21:41:50 +1000, Fr?d?ric Trottier-H?bert < > fred.hebert@REDACTED> wrote: > > > >> I would rather have one clear but slightly verbose way of doing things > rather than two potential ways to do the same thing in slightly different > manners prompting religious wars to get the same result I already have. > >> > >> The idea to revisit the syntax isn't bad in itself, but looking at the > examples Steve Davis provided, I can only see your concept being useful for > very short functions. > >> > >> When it comes to learning Erlang, I can tell you that in my experience, > new users struggle a lot more with clause separators (;), expression > separators (,), form terminators (.), records, 'if' or funs (in concept) > than they do with function syntax. They do not seem to see the current way > to write function heads as problematic. Then, all Erlang users are also used > to it. > >> > >> Adding more ways to do things that currently have a single way to be > done is a net loss in my opinion. People already complain that Erlang's > syntax is too ugly or complex; I do not think that adding more syntax is the > way to solve that. It would not benefit new users and it would not benefit > the majority of all users, only increase the ways they can read code and get > confused. > >> > >> In the other thread, someone called it 'syntactic salt', and I think > this is a good way to describe how things are right now. It's not a bad > thing in my opinion. > >> > >> On 2011-05-19, at 06:47 AM, Michael Turner wrote: > >> > >>> "But how interesting is whether existing code would break or not?" > >>> > >>> Not very. I mean, who uses Erlang for anything important? Hardly > anybody, right? > >>> > >>> [/sarcasm] > >>> > >>> "It would, as others have pointed out, also be much harder to jump into > a module and _know_ what the clause does since the function's name can be > pages away." > >>> > >>> It would only be harder ("much"??) if you *chose*, in such cases, to > use the syntax I propose to bring over from multi-clause funs. In the case > you bring up, it might be wiser not to. And what I propose clearly allows > everyone to continue with the present syntax. So your argument for > readability in this case comes down to "somebody might not use this language > feature wisely." (*facepalm*). > >>> > >>> -michael turner > >>> _______ > >>> erlang-questions mailing list > >>> erlang-questions@REDACTED > >>> http://erlang.org/mailman/listinfo/erlang-questions > >> > >> -- > >> Fred H?bert > >> http://www.erlang-solutions.com > > > > > > -- > > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Fri May 20 05:01:20 2011 From: ok@REDACTED (Richard O'Keefe) Date: Fri, 20 May 2011 15:01:20 +1200 Subject: [erlang-questions] 'reply-to' header in this mailing list In-Reply-To: References: <20110517142848.GA9263@erix.ericsson.se> <230D6DBF-EE90-475F-A973-DF0E7B71EF19@cs.otago.ac.nz> Message-ID: I should like to point out that the *proposal* to change the currently very sensible behaviour of this list has *already* cost me far more time than any change would credibly save me. When you add up all the other people who've been following it, the waste of time is quite scary. IF YOU DON'T LIKE IT, LEARN TO USE THE "REPLY ALL" BUTTON ALL THE TIME. From jws@REDACTED Fri May 20 05:45:35 2011 From: jws@REDACTED (Jeff Schultz) Date: Fri, 20 May 2011 13:45:35 +1000 Subject: [erlang-questions] Advanced Erlang Subtleties In-Reply-To: References: Message-ID: <20110520034535.GA6320@mulga.csse.unimelb.edu.au> On Thu, May 19, 2011 at 11:02:35PM +0200, Joe Armstrong wrote: > > I can see the equivalent evaluation of "250"<250 being a common mistake, > > and always being false is hardly useful. > A "<" B when A and B have different types means A is > "less complex" than B. Lists and more complex than integers > "250" is a list so "250"<250 is false. > Suppose I want to make a Key-Value database, where the Key can be anything, > including 250 and "250" to make any form of ordered tree we need a total > order over all the keys. Indeed. If we can have only one built-in comparison, it needs to be total over all values. It is a pity that Prolog's distinction between term comparison and number comparison wasn't carried over to Erlang :-( Jeff Schultz From michael.eugene.turner@REDACTED Fri May 20 06:34:41 2011 From: michael.eugene.turner@REDACTED (Michael Turner) Date: Fri, 20 May 2011 13:34:41 +0900 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: <1930B4D4-54DD-4F80-ACDE-BBE983315E64@hates.ms> <20110519093746.GB27904@erix.ericsson.se> <7418517D-4A84-4F44-94E8-B15045F5DAC0@erlang-solutions.com> <1DB4D10E-B83D-4E69-8888-18CE552DC785@erlang-solutions.com> Message-ID: "this particular feature makes perfect sense to me in its current form." ... having arrived, as you said, with experience from e.g., Haskell, having similar syntax. This is a little like saying, "I had no trouble with riding a bicycle when I first tried it -- although to be fair, my experiments with riding a unicycle gave me a slight head start in terms of skills." As someone above reported, Clojure dispenses with the need to name the function for every clause; if you'd only comparable experience had been with Clojure, you might have found Erlang syntax strangely inconsistent, inconvenient, and a little hard to learn. Look, from my experience with Prolog, Erlang's way *also* made perfect sense to me in its current form. But the arguments I make here apply with almost equal weight to Prolog anyway -- I found the repetition vaguely annoying at the time. And the first time I tried to write a multi-clause fun in Erlang I was hobbled by the preconceptions set both by Prolog and by Erlang's standard style (and by the spottiness of the official documentation for multi-clause funs -- I found it first in Joe's book before I found it online.) -michael turner On Fri, May 20, 2011 at 9:57 AM, Daniel Dormont wrote: > Speaking as a relative newb with experience in other languages, I agree. > Perhaps my experience is unusual (though honestly, I don't think so) in that > I've spent some quality time with Haskell and Standard ML before coming to > Erlang, but this particular feature makes perfect sense to me in its current > form. > > What I'd love is to have this in nested functions too. I don't care much > care about syntactic consistency for its own sake (heck, Perl is one of my > favorite languages, what does that tell you) so that's not my motivation; > what excites me is being able to have recursive closures. > > dan > > 2011/5/19 Fr?d?ric Trottier-H?bert > >> I don't agree with complaints either -- I have no issue with Erlang's >> syntax, lisp/scheme/racket's syntax or any other language. The reality, >> however, is that while programmers can pick up Erlang's syntax quickly, >> there's still an initial struggle to break what has been committed to muscle >> memory by many of the people I have taught it to. >> >> The syntax might be the scapegoat of the difficulty in learning foreign >> concepts like functional paradigms, concurrent ideas or pattern matching, >> but in any case, it is a hurdle that newcomers have to step over. It's not >> because they can beat challenges that we have to make it harder on purpose >> by introducing new elements like the alternative function syntax. >> >> -- >> Fred H?bert >> http://www.erlang-solutions.com >> >> >> >> On 2011-05-19, at 18:49 PM, Edmond Begumisa wrote: >> >> >> People already complain that Erlang's syntax is too ugly or complex; >> > >> > I've always found this complaint to be rather quibble. >> > >> > Programmers have brains that are extremely well adjusted to parsing new >> syntax. This is one thing all programmers are inherently good at. Yet when >> asked to put this skill towards learning a new language, they complain. "No" >> they say, "give me a syntax I'm already familiar with. Why are you trying to >> be different?" they ask. >> > >> > I learned Erlang by reading Joe's book. Within half an hour I wasn't >> seeing the syntax anymore. My brain, quickly made the necessary mental >> mappings. I strongly believe this to be the case with all programmers when >> encountering an unfamiliar syntax -- rapid adjustment with relatively little >> effort. >> > >> > Other professions are not so lucky. I once witnessed two non-programmers >> trying to learn HTML at the same time. One a medical doctor, the other a >> graphic designer. Both got the concepts down very quickly (links, images, >> tables, etc), but both really struggled with syntax. "How can one possibly >> read this?" they kept asking. >> > >> > Yet most programmers learn HTML/XML syntax in a matter of minutes while >> watching TV. Gut give them Erlang and they groan and complain loudly. >> > >> > IMHO, complaints about Erlang's syntax being "too weird" are completely >> unwarranted. A programmer could learn a language written using Klingon >> symbols in a unbelievably short period of time. Just look at all those >> non-English speakers who program in languages heavily biased towards >> English. And many of them come from languages using non-latin scripts!!! >> > >> > - Edmond - >> > >> > PS: The exception is Lisp. All those parentheses are just obfuscating :) >> > >> > >> > >> > On Thu, 19 May 2011 21:41:50 +1000, Fr?d?ric Trottier-H?bert < >> fred.hebert@REDACTED> wrote: >> > >> >> I would rather have one clear but slightly verbose way of doing things >> rather than two potential ways to do the same thing in slightly different >> manners prompting religious wars to get the same result I already have. >> >> >> >> The idea to revisit the syntax isn't bad in itself, but looking at the >> examples Steve Davis provided, I can only see your concept being useful for >> very short functions. >> >> >> >> When it comes to learning Erlang, I can tell you that in my experience, >> new users struggle a lot more with clause separators (;), expression >> separators (,), form terminators (.), records, 'if' or funs (in concept) >> than they do with function syntax. They do not seem to see the current way >> to write function heads as problematic. Then, all Erlang users are also used >> to it. >> >> >> >> Adding more ways to do things that currently have a single way to be >> done is a net loss in my opinion. People already complain that Erlang's >> syntax is too ugly or complex; I do not think that adding more syntax is the >> way to solve that. It would not benefit new users and it would not benefit >> the majority of all users, only increase the ways they can read code and get >> confused. >> >> >> >> In the other thread, someone called it 'syntactic salt', and I think >> this is a good way to describe how things are right now. It's not a bad >> thing in my opinion. >> >> >> >> On 2011-05-19, at 06:47 AM, Michael Turner wrote: >> >> >> >>> "But how interesting is whether existing code would break or not?" >> >>> >> >>> Not very. I mean, who uses Erlang for anything important? Hardly >> anybody, right? >> >>> >> >>> [/sarcasm] >> >>> >> >>> "It would, as others have pointed out, also be much harder to jump >> into a module and _know_ what the clause does since the function's name can >> be pages away." >> >>> >> >>> It would only be harder ("much"??) if you *chose*, in such cases, to >> use the syntax I propose to bring over from multi-clause funs. In the case >> you bring up, it might be wiser not to. And what I propose clearly allows >> everyone to continue with the present syntax. So your argument for >> readability in this case comes down to "somebody might not use this language >> feature wisely." (*facepalm*). >> >>> >> >>> -michael turner >> >>> _______ >> >>> erlang-questions mailing list >> >>> erlang-questions@REDACTED >> >>> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> >> -- >> >> Fred H?bert >> >> http://www.erlang-solutions.com >> > >> > >> > -- >> > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ >> >> _______________________________________________ >> >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.eugene.turner@REDACTED Fri May 20 07:29:50 2011 From: michael.eugene.turner@REDACTED (Michael Turner) Date: Fri, 20 May 2011 14:29:50 +0900 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: <661C1ED1-0683-435C-8BF0-5EAB2289D546@erlang-solutions.com> References: <661C1ED1-0683-435C-8BF0-5EAB2289D546@erlang-solutions.com> Message-ID: Thank you, Fr?d?ric, for taking a serious look at the idea. However, I see a few of the same unsubstantiated objections raised, with a couple more questionable ones added. "- It makes it less obvious that a function has many clauses (see Steve Davis' code)" WITH Steve's style of indentation. I suggested a more readable alternative, where the "(Args)->" part has indentation column to themselves. (Curiously, you employ my suggested indentation style yourself, below, in a supposedly "ambiguous" code sample.) "- it somewhat unifies the syntax with funs, but then funs still finish with 'end' and take no name." Perhaps syntax would become even more regular than you suggest. What I propose results in a grammar more like this: function: clause-list + "." fun: "fun" + clause-list + "end" clause: [optional name] (arg-list) guards -> stmt-list This is, if anything, more regular than the grammar is now. Yes, it *syntactically* allows for a *different* "optional name", but so does the current grammar; finding head mismatches *already* requires a separate step. And I question whether it requires the parser to produce a different AST than we get now, for parse-transform purposes. The above syntax also permits naming in funs. Is that so bad? As ROK has suggested, pehaps funs ought to be allowed (limited-scope) names to facilitate recursive definition. I happen to think it would work just as well to re-use the keyword "fun" to refer to the fun in the process of being defined. But there's something to be said for self-documenting recursive funs, so I could go either way on that one. Or both ways. (I hear the moans: "Not *another* way to do the same thing..." -- as if they were actually the same. And as if I weren't proposing here to do things ONE way.) "- it creates more learning overhead if both forms are used." That depends on how you learn (and teach) a language. Really: how much more page space does it require to show a slightly different way to do something? And then there are different learner styles. After learning the basics of a language, I tend to flip to an appendix like "syntax summary" (in BNF and other semi-formal styles), to start exploring the meaning of different combinatorial possibilities -- it's often one of the most clarifying and delightful exercises I undertake. Alas, neither of the Erlang books has any such an appendix (mandatory for a programming language primer, I would have thought.) For me, that has made learning Erlang harder. "- it's not faster (compile time, might even make compiling slower)" You've got to be kidding. It's long been known: the time complexity of parsing is overwhelmingly dominated by scanning. Code written in the form I propose would have fewer tokens to scan. "- it doesn't make the parser code easier to maintain" It might, actually. See above. "- it's making a lot of documentation obsolete that will need to be updated. This is common to all changes though." Yes, it is. Not to mention that the documentation on Erlang syntax is due for an upgrade anyway. The first hit I get on "Erlang" and "fun" yields the section "Syntax of funs", here: http://www.erlang.org/doc/programming_examples/funs.html#id59209 Yes, believe it: no coverage of the multi-clause case. "You'll be creating a hell of a lot more work ...." Ah, it seems almost obligatory on this thread: exaggeration asserted as fact. Would it really require even as much as a day's work on the parser? Yes, it would require updating documentation of Erlang syntax, but that documentation that (see above) clearly needs a little work anyway. "Oh and lastly, you could also have to consider this ambiguity ...." It wouldn't even be an ambiguity. It would only be a weird and pointless way to write that code. And that's IF someone wrote code like that. Well, anybody can write crappy and confusing code that abuses any language feature. (There it is: my own obligatory exaggeration for this thread.) Any "obfuscated Erlang contest" would likely to whack the worst Obfuscated C out the ballpark. (And that's no exaggeration.) -michael turner 2011/5/19 Fr?d?ric Trottier-H?bert > Well let's take a look here. Syntax doesn't have to break old code to > change, that's a good point. > > You'll see that if you try {lists, sort}([3,2,1]), you will obtain [1,2,3]. > This basic fun syntax dates from before Erlang actually had funs (fun > M:F/A). You'll notice that it was less complex, tends to avoid verbosity and > is somewhat more readable than doing (fun lists:sort/1)([1,2,3]). Going to > the new syntax didn't break any code, didn't require old working code to be > rewritten (things still work the old way, and parametrized modules are based > on that bit of syntax) and people just ignore it if they don't need it. Yet > people did the switch from {Mod, Fun} to fun M:F/A. > > Why? Because, I figure, people generally liked the new way better: it's > faster (apparently much faster), much cleaner in intent and purposes, and > way easier to figure out that we're actually dealing with a higher order > function and not some weird concept. Plus you have to consider that in many > places, you can just use 'Var(Args)' with either form. This switch had many > wins over conciseness. > > If we try to do the same with your suggestion for the new Erlang syntax, we > can basically see that it has a few advantages: > > - reduces typing required by avoiding name repetitions > - it doesn't break existing code > - it somewhat unifies the syntax with funs, but then funs still finish with > 'end' and take no name. > > > I, however, see the following disadvantages: > > - it creates multiple standards left to personal preference > - it makes it less obvious that a function has many clauses (see Steve > Davis' code) > - it creates more learning overhead if both forms are used. {Mod,Fun} for > funs has no overhead because it's basically deprecated and nobody uses it. > - All the existing tools have to be updated to understand it -- at least > those working on source files (and this includes editors and whatnot) > > To this, you must add a multiplier damage (heh) for things it doesn't make > better: > - it's not faster (compile time, might even make compiling slower) > - it doesn't make the parser code easier to maintain > - it doesn't make maintaining code in modules easier (except for some > readability benefits) > - it's not helping people understand the language better (based on my > observations that people have no problems with the current form when it > comes to understanding) > - it's making a lot of documentation obsolete that will need to be updated. > This is common to all changes though. > > In my opinion, typing less code, even if it doesn't break compatibility, is > not worth the change. You'll be creating a hell of a lot more work if only > to get a bit more concise and consistent syntax on a thing where people > don't even agree you get better readability. > > > Oh and lastly, you could also have to consider this ambiguity -- is the > following bit of code acceptable? > > my_function > (a,b,c) -> {a,b,c}; > (a,c,b) -> {a,b,v}; > my_function > (c,b,a) -> {a,b,c}. > > > On 2011-05-19, at 09:43 AM, Michael Turner wrote: > > > "Erlang is sufficiently mature that the syntax is now very difficult to > change." > > > > Nobody has yet told me why this proposed change would break any existing > code, or why it would require any significant work on the parser. > > > -- > Fred H?bert > http://www.erlang-solutions.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Fri May 20 08:10:48 2011 From: ok@REDACTED (Richard O'Keefe) Date: Fri, 20 May 2011 18:10:48 +1200 Subject: [erlang-questions] What are the "Most valuable libraries?"...and a few other questions In-Reply-To: References: <20110517142848.GA9263@erix.ericsson.se> <230D6DBF-EE90-475F-A973-DF0E7B71EF19@cs.otago.ac.nz> <4DD311FF.2090402@gmail.com> Message-ID: <1B641F41-EE9F-40BC-B0CB-7AAD5C26D750@cs.otago.ac.nz> > On Tue, May 17, 2011 at 5:25 PM, Todd wrote: > 4b. Side note: is anyone concerned about Akka/Typesafe stealing mindshare? Having read Williamson's "Legion of Space" series, I would feel rather unhappy using AKKA (:-). From mazen.harake@REDACTED Fri May 20 08:35:28 2011 From: mazen.harake@REDACTED (Mazen Harake) Date: Fri, 20 May 2011 08:35:28 +0200 Subject: [erlang-questions] 'reply-to' header in this mailing list In-Reply-To: References: <20110517142848.GA9263@erix.ericsson.se> <230D6DBF-EE90-475F-A973-DF0E7B71EF19@cs.otago.ac.nz> Message-ID: First thing I said heh. no one listened... :( Looking forward to having the same discussion in a few months time again :P On 20 May 2011 05:01, Richard O'Keefe wrote: > I should like to point out that the *proposal* to change the > currently very sensible behaviour of this list has *already* > cost me far more time than any change would credibly save me. > When you add up all the other people who've been following > it, the waste of time is quite scary. > > IF YOU DON'T LIKE IT, LEARN TO USE THE "REPLY ALL" BUTTON > ALL THE TIME. > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Fri May 20 08:41:40 2011 From: ok@REDACTED (Richard O'Keefe) Date: Fri, 20 May 2011 18:41:40 +1200 Subject: [erlang-questions] 'reply-to' header in this mailing list In-Reply-To: <600128661.198501305727597470.JavaMail.root@zimbra> References: <600128661.198501305727597470.JavaMail.root@zimbra> Message-ID: <1A9E48A8-3609-40FB-925F-6D9FF62BDAFA@cs.otago.ac.nz> On 19/05/2011, at 2:06 AM, Robert Virding wrote: > How about we completely side-step the whole issue and re-structure the various erlang mailing lists a forum instead? And by choosing one of the common and free forum packages we will automatically get a standard (in the sense of being common and much used) behaviour. > > This is also a serious suggestion. Please please please PLEASE PLEASE do not do that. From mjtruog@REDACTED Fri May 20 08:59:16 2011 From: mjtruog@REDACTED (Michael Truog) Date: Thu, 19 May 2011 23:59:16 -0700 Subject: [erlang-questions] What are the "Most valuable libraries?"...and a few other questions In-Reply-To: <1B641F41-EE9F-40BC-B0CB-7AAD5C26D750@cs.otago.ac.nz> References: <20110517142848.GA9263@erix.ericsson.se> <230D6DBF-EE90-475F-A973-DF0E7B71EF19@cs.otago.ac.nz> <4DD311FF.2090402@gmail.com> <1B641F41-EE9F-40BC-B0CB-7AAD5C26D750@cs.otago.ac.nz> Message-ID: <4DD61144.3060903@gmail.com> On 05/19/2011 11:10 PM, Richard O'Keefe wrote: >> On Tue, May 17, 2011 at 5:25 PM, Todd wrote: >> 4b. Side note: is anyone concerned about Akka/Typesafe stealing mindshare? > Having read Williamson's "Legion of Space" series, I would feel rather > unhappy using AKKA (:-). Not sure if you saw it, but there now is pykka (for python, at https://github.com/jodal/pykka ). Even if these and other libraries (jetlang is the basis for akka, kilim which came before it, in the Java world, etc.) support message passing based scheduling of light-weight processes in a way that facilitates creating Actors, the libraries are unlikely to perform as well as Erlang because: - The amount of research/development that has gone into Erlang - The process-based garbage collection which can not be found through a message passing library Ok, even if the message based scheduling of light-weight processes is as efficient (comparable) to Erlang (ignoring garbage collection problems), a library will not give you code-level fault-tolerance (unless you go through a lot of painful development with custom code that lacks testing and increases the complexity of your codebase). So, I do not think there will be an Erlang replacement anytime soon. From steve@REDACTED Fri May 20 09:12:09 2011 From: steve@REDACTED (Steve Strong) Date: Fri, 20 May 2011 09:12:09 +0200 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: <661C1ED1-0683-435C-8BF0-5EAB2289D546@erlang-solutions.com> Message-ID: <3E70F4ECA6ED459C936583EE3B7301EC@srstrong.com> Do you seriously think that a compiler team of a well-established and widely used language would implement a new syntax in less than a day? The code change itself may be relatively trivial (or a total pain in the arse, I've not looked at the current compiler code and could believe either), but whichever it is, it will be dwarfed by the design meetings held prior to making the change - looking at both backward *and* forward compatibility issues (what sort of things might this change prevent us from doing in the future?), plus the testing that would need to be performed after. And then there's all the tools that would be broken. Emacs for one would need work since it's syntax highlighting would now be broken. All this for a really minor change that, judging from the responses on this list, not that many people even want. Dude, this thread has gone on long enough and wasted way too much time. If this is so important to you, then do it yourself (after all, it's less than a days work) and publish the changes. Cheers, Steve -- Steve Strong, Director, id3as twitter.com/srstrong On Friday, 20 May 2011 at 07:29, Michael Turner wrote: > Thank you, Fr?d?ric, for taking a serious look at the idea. However, I see a few of the same unsubstantiated objections raised, with a couple more questionable ones added. > > "- It makes it less obvious that a function has many clauses (see Steve Davis' code)" > > WITH Steve's style of indentation. I suggested a more readable alternative, where the "(Args)->" part has indentation column to themselves. (Curiously, you employ my suggested indentation style yourself, below, in a supposedly "ambiguous" code sample.) > > "- it somewhat unifies the syntax with funs, but then funs still finish with 'end' and take no name." > > Perhaps syntax would become even more regular than you suggest. What I propose results in a grammar more like this: > > function: > clause-list + "." > fun: > "fun" + clause-list + "end" > clause: > [optional name] (arg-list) guards -> stmt-list > > This is, if anything, more regular than the grammar is now. Yes, it *syntactically* allows for a *different* "optional name", but so does the current grammar; finding head mismatches *already* requires a separate step. And I question whether it requires the parser to produce a different AST than we get now, for parse-transform purposes. > > The above syntax also permits naming in funs. Is that so bad? As ROK has suggested, pehaps funs ought to be allowed (limited-scope) names to facilitate recursive definition. I happen to think it would work just as well to re-use the keyword "fun" to refer to the fun in the process of being defined. But there's something to be said for self-documenting recursive funs, so I could go either way on that one. Or both ways. (I hear the moans: "Not *another* way to do the same thing..." -- as if they were actually the same. And as if I weren't proposing here to do things ONE way.) > > "- it creates more learning overhead if both forms are used." > > That depends on how you learn (and teach) a language. Really: how much more page space does it require to show a slightly different way to do something? And then there are different learner styles. After learning the basics of a language, I tend to flip to an appendix like "syntax summary" (in BNF and other semi-formal styles), to start exploring the meaning of different combinatorial possibilities -- it's often one of the most clarifying and delightful exercises I undertake. Alas, neither of the Erlang books has any such an appendix (mandatory for a programming language primer, I would have thought.) For me, that has made learning Erlang harder. > > "- it's not faster (compile time, might even make compiling slower)" > > You've got to be kidding. It's long been known: the time complexity of parsing is overwhelmingly dominated by scanning. Code written in the form I propose would have fewer tokens to scan. > > "- it doesn't make the parser code easier to maintain" > > It might, actually. See above. > > "- it's making a lot of documentation obsolete that will need to be updated. This is common to all changes though." > > Yes, it is. Not to mention that the documentation on Erlang syntax is due for an upgrade anyway. The first hit I get on "Erlang" and "fun" yields the section "Syntax of funs", here: > > http://www.erlang.org/doc/programming_examples/funs.html#id59209 > > Yes, believe it: no coverage of the multi-clause case. > > "You'll be creating a hell of a lot more work ...." > > Ah, it seems almost obligatory on this thread: exaggeration asserted as fact. Would it really require even as much as a day's work on the parser? Yes, it would require updating documentation of Erlang syntax, but that documentation that (see above) clearly needs a little work anyway. > > "Oh and lastly, you could also have to consider this ambiguity ...." > > It wouldn't even be an ambiguity. It would only be a weird and pointless way to write that code. And that's IF someone wrote code like that. Well, anybody can write crappy and confusing code that abuses any language feature. (There it is: my own obligatory exaggeration for this thread.) Any "obfuscated Erlang contest" would likely to whack the worst Obfuscated C out the ballpark. (And that's no exaggeration.) > > -michael turner > 2011/5/19 Fr?d?ric Trottier-H?bert > > Well let's take a look here. Syntax doesn't have to break old code to change, that's a good point. > > > > You'll see that if you try {lists, sort}([3,2,1]), you will obtain [1,2,3]. This basic fun syntax dates from before Erlang actually had funs (fun M:F/A). You'll notice that it was less complex, tends to avoid verbosity and is somewhat more readable than doing (fun lists:sort/1)([1,2,3]). Going to the new syntax didn't break any code, didn't require old working code to be rewritten (things still work the old way, and parametrized modules are based on that bit of syntax) and people just ignore it if they don't need it. Yet people did the switch from {Mod, Fun} to fun M:F/A. > > > > Why? Because, I figure, people generally liked the new way better: it's faster (apparently much faster), much cleaner in intent and purposes, and way easier to figure out that we're actually dealing with a higher order function and not some weird concept. Plus you have to consider that in many places, you can just use 'Var(Args)' with either form. This switch had many wins over conciseness. > > > > If we try to do the same with your suggestion for the new Erlang syntax, we can basically see that it has a few advantages: > > > > - reduces typing required by avoiding name repetitions > > - it doesn't break existing code > > - it somewhat unifies the syntax with funs, but then funs still finish with 'end' and take no name. > > > > > > I, however, see the following disadvantages: > > > > - it creates multiple standards left to personal preference > > - it makes it less obvious that a function has many clauses (see Steve Davis' code) > > - it creates more learning overhead if both forms are used. {Mod,Fun} for funs has no overhead because it's basically deprecated and nobody uses it. > > - All the existing tools have to be updated to understand it -- at least those working on source files (and this includes editors and whatnot) > > > > To this, you must add a multiplier damage (heh) for things it doesn't make better: > > - it's not faster (compile time, might even make compiling slower) > > - it doesn't make the parser code easier to maintain > > - it doesn't make maintaining code in modules easier (except for some readability benefits) > > - it's not helping people understand the language better (based on my observations that people have no problems with the current form when it comes to understanding) > > - it's making a lot of documentation obsolete that will need to be updated. This is common to all changes though. > > > > In my opinion, typing less code, even if it doesn't break compatibility, is not worth the change. You'll be creating a hell of a lot more work if only to get a bit more concise and consistent syntax on a thing where people don't even agree you get better readability. > > > > > > Oh and lastly, you could also have to consider this ambiguity -- is the following bit of code acceptable? > > > > my_function > > (a,b,c) -> {a,b,c}; > > (a,c,b) -> {a,b,v}; > > my_function > > (c,b,a) -> {a,b,c}. > > > > > > On 2011-05-19, at 09:43 AM, Michael Turner wrote: > > > > > "Erlang is sufficiently mature that the syntax is now very difficult to change." > > > > > > Nobody has yet told me why this proposed change would break any existing code, or why it would require any significant work on the parser. > > > > > > -- > > Fred H?bert > > http://www.erlang-solutions.com > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Fri May 20 09:42:04 2011 From: ok@REDACTED (Richard O'Keefe) Date: Fri, 20 May 2011 19:42:04 +1200 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: Message-ID: On 19/05/2011, at 2:18 AM, Michael Turner wrote: > Another objection raised against this syntax change is that all functional languages violate DRY in this manner, so it's OK if Erlang does it too. This is a Principle of Least Surprise argument, and not bad as far as it goes. But how far does it go? > > Erlang will have a better chance of greater success and survival if you consider your recruitment base to be the overwhelming majority of programmers. I had a lengthy response to this which SquirrelMail (apparently that's the name of the WebMail system here) managed to destroy. Sigh. Erlang has already survived very well for 30+ years with pretty much its present syntax. It has also succeeded very well. > And from what I can tell, > > http://www.langpop.com > > the overwhelming majority of programmers have no experience to speak of, Erlang's strengths come from being DIFFERENT. There's a thing much discussed, much derided, and much practiced in Australia and New Zealand, called "cultural cringe". Look it up. Cultural cringe hurt ISO Prolog. (Prolog _had_ a notation for integers in bases 2..36, but the ISO committee threw it away and copied C instead, for base 16 only. They also changed the precedence of at least one operator to match C better than Prolog.) If we go by fashion, we'll change Erlang to look like PHP or COBOL. (Estimates of COBOL code volume range from 1e11 to 5e11 lines.) Oh, I'd like all sorts of changes to Erlang syntax. After Haskell, I find it quite verbose. I once designed a "Haskerl" syntax for Erlang that reduced the line count by a factor of 1.6. But syntax is not the most important thing about Erlang (or LFE would not be of interest), and it's not really what needs the most attention. I think the Dialyzer is easily the most dramatic and important thing that's happened to Erlang in some time, and if we want to talk about improvements, that might have the highest payoff. > when it comes to functional programming languages. Appealing to the "cross-training" benefit of coming from other FP languages seems like a pretty weak argument. Especially since all I'm asking for here is syntactic consistency *within* Erlang -- a PLoS argument in itself. > > Richard O'Keefe suggests that the syntactic consistency goal is better met by allowing a kind of limited-scope special-case fun name, permitting, e.g. > > Fact = fun F(0) -> 1; F(N) -> N*F(N-1) end. > > I could get behind that too, but I don't follow his reasoning from syntactic consistency, which is apparently that an unnamed fun has a name, it's just the degenerate case of a name. It's really there. We just can't see it. Hm, really? If that were true in Erlang as it stands, shouldn't I be able to write it this way? > > Fact = fun (0) -> 1; (N) -> N*''(N-1) end. Because (a) the generalisation I suggested was fun {; }... end where is either a VARIABLE or omitted, and is identical in each clause. But '' is NOT a variable, now is it? And (b) the generalisation I suggested was to use the SAME in each clause, and a completely missing name is NOT the same as an empty but present atom. (This is like the way that in SQL92 a NULL string is very different from an empty string.) And note that I did not say that this is what Erlang *DOES* do but what it might some day be *EXTENDED* to do as a way of letting people write recursive funs. By the way, some earlier posting from somebody said that Erlang was alone in allowing multiple clauses in funs. Not so. Erlang Haskell ML yes yes no Are multiple arguments allowed in a lambda? yes no yes Are multiple clauses allowed in a lambda? Erlang: fun ([_|_]) -> true ; ([]) -> false end Standard ML: fn (_:_) -> true | [] -> false While you *can* write val default = fn (SOME x) _ -> x | NONE d -> d in SML, it is normal practice to write fun default (SOME x) _ = x | default NONE d = d and I think most SML programmers would regard the first alternative as perversely unreadable. > > > What Richard's suggesting appears to require a rigorous re-think of how scopes are defined in Erlang. Not in the least. The scope of a function name variable would be the function itself, just like any other variable in the arguments of the clauses. 1> X = 1. 1 2> F = fun (X) -> ok ; (_) -> uh_oh end. #Fun 3> F(2). ok See how the X in the fun was *not* the X outside? Same rule exactly for fun-names. > W > hat I'm suggesting amounts to simply asking the compiler to do some of your tedious keying for you. > > -michael turner (A) If repeating the function name is the most tedious keying you have, how fortunate you are! (B) People with a decent text-editor don't have a problem anyway. One reason for putting case, if, fun, and receive semicolons at the beginning of the line is so that when you end a line with a semicolon, the editor can automatically - go back to the first preceding line to have a letter or ' in column 1; - copy the function name into a work space - go back where it started - insert the work space. I did this years ago for Prolog. I found it distracting, so switched the feature off, but anyone who really really hated retyping function names should be able to program this in a few minutes. (C) The names are not there for the benefit of the compiler, but for the benefit of PEOPLE. When you are reading someone else's code, it HELPS to see the function name in each clause. And that's why I'm willing to give head-room to fun-names. I really loathe seeing a bare argument list without any indication of what it's the argument list *of*. > > > On Wed, May 18, 2011 at 6:16 PM, Michael Turner wrote: > I can say > > fun (1)->2; > (2)->1 > end > > but, oddly, I can't define a named function in the analogous way, e.g.: > > factorial > (1) -> 1; > (N) -> N*factorial(N-1). > > gives me a syntax error. I find the latter more readable than > > factorial(1) -> 1; > factorial(2) -> N*fact(N-1). I do not. In fact I find the first version of factorial rather horrible. If you really want to do that, you can write factorial(N) -> case N of (1) -> 1; (N) -> N*factorial(N-1) end. right now. Just don't ask me to read it for anything less than NZD 400/hour. > > It's also less to type and to read, which is consistent with the DRY principle ("Don't Repeat Yourself"). The DRY principle was not handed down on Mt Sinai. It is a rule of thumb, no more and no less. And indeed, it violates something I have found to be an excellent guide, that a *controlled* use of redundancy is an aid to correctness. For example, :- spec is redundant, but - it lets Erlang detect a difference between what you DID write and what you MEANT to write - someone can read the :- spec without having to read the code. There are other examples of good redundancy in Erlang. The keyword here, of course, is *controlled* redundancy; just enough to do something useful (like helping human beings read your code, or permitting some check), not too much. > It also looks a *little* bit more like the mathematical convention for defining these sorts of functions, where you have "f(x) = ", centered vertically to the left of a big left "{" that (left-)encloses the list of expression/parameter-condition pairs in a two-column format, e.g., That is one mathematical convention, followed in Miranda, and leading to guards in Haskell and Erlang. It is regrettable that SML does not have them, but at least there's the 'nowhere' preprocessor to provide them. There are other mathematical conventions. "The Fibonacci numbers are defined using the linear recurrence relation -------------- next part -------------- A non-text attachment was scrubbed... Name: 4759a679404fa38e0954b0adffcfd960.png Type: image/png Size: 479 bytes Desc: not available URL: -------------- next part -------------- with seed values: -------------- next part -------------- A non-text attachment was scrubbed... Name: de489126f6f0351ecd9112c3d59a40be.png Type: image/png Size: 354 bytes Desc: not available URL: -------------- next part -------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: a0d53c9950d78244ed03c613cad5bdd1.png Type: image/png Size: 304 bytes Desc: not available URL: -------------- next part -------------- " (Wikipedia entry on recurrence relations). This is the style that Haskell, Clean, Mercury, SML, CAML, and so on follow. > It seems to me that, if anything, this requires only a *simplification* of the Erlang parser. That leaves only one obvious objection: would any existing code break if Erlang syntax were altered to allow this? Probably not. However, the parser is a tiny part of the Erlang system, even a tiny part of the compiler. Simplicity of the parser per se is hardly worth worrying about. What matters is having a readable language. Even if the change were made, every Erlang book and paper ever printed shows the existing style. How would newbies react to code that looked like nothing they had ever been taught about? What would happen to Erlang language-sensitive editing tools, would they cope with the new syntax? I know that the crude pretty-printer I wrote for Erlang would have trouble, and the commands I now find useful for moving to the next/previous clause would cease to work. From raimo+erlang-questions@REDACTED Fri May 20 10:05:24 2011 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Fri, 20 May 2011 10:05:24 +0200 Subject: [erlang-questions] 'reply-to' header in this mailing list In-Reply-To: References: <688144131.198481305727593991.JavaMail.root@zimbra> <600128661.198501305727597470.JavaMail.root@zimbra> <016d01cc1642$bc4dce10$34e96a30$@com> <20110519165711.GQ7320@aluminum.local> Message-ID: <20110520080524.GA27692@erix.ericsson.se> On Thu, May 19, 2011 at 06:01:31PM -0600, OvermindDL1 wrote: > On May 19, 2011 10:57 AM, "Vance Shipley" wrote: > > > > On Thu, May 19, 2011 at 11:35:14AM -0500, David Mercer wrote: > > } Can someone please elucidate the distinction between a mailing > > } list and a forum? > > > > I have come to the conclusion that what is beneath these sort > > of debates amounts to a generational gap. Those who grew up > > with a mouse in their hands have different expectations than > > those of us who grew up with our hands planted on the keyboard > > looking at a command prompt. As one of the later my view is > > that the distinction is: > > > > mailing list: push > > forum: pull > > > > -- > > -Vance > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > Why can it not just be configurable on a person by person basis by editing > their own user preferences on the mailing list server? > > Certainly the mailing list software is not so poorly designed so as to > require such a person specific option to be set only globally. ;-) Oh yes it is, I hope "poorly designed" was the reason for the ";-)". I have run some mailing lists and only looked at running forums, but they are different software packages. Popular mailing list softwares are e.g "Mailman" or "Majordomo", forums "phpBB", "UseBB", "WWWBoard", "YaBB", etc. A mailing list is centered around the mails. Users posts by sending a mail to the list, the software distributes the mail to all subscirbers and possibly keeps an archive of all posts. Often the origin address of the mail is used to verify that a mail is valid to post. And that is about it. A forum is centered about the archive/bulletin board. Users have to log on, there has to be a web server handling the user session, the post is written through a web interface, users have more settings e.g an Avatar and there has to be permission handling of which user is allowed to post to which forum section. There has to be moderators that can completely delete threads that are inappropriate (in mailing lists changing the archive is rare done since all subscribers know all posts anyway). You can often get a mail when a thread you are "watching" is updated but you are supposed to read through the web interface. Forums can have mailing list extensions so you can post by sending a mail, possibly also get the posts as mails. I have been on forums where this appeared to be upcoming features but were not enabled... So, mailing list software is designed so that the forum model is not on the map at all except keeping an archive. Forum software may be designed to act as mailing lists, but I do not know how well they do it. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From ok@REDACTED Fri May 20 10:07:06 2011 From: ok@REDACTED (Richard O'Keefe) Date: Fri, 20 May 2011 20:07:06 +1200 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: Message-ID: <749E5278-61D7-4A58-82D0-A128D0972C97@cs.otago.ac.nz> On 19/05/2011, at 3:46 AM, Michael Turner wrote: > "You're being pedantic dude." > > If I argued only from syntactic consistency, you'd have a point. Frankly, I don't really care about syntactic consistency, if it doesn't get me something. Having to type less gets me something. Having more readable code gets me something. Those are practical considerations, not mere pedantic ones. Dude. > > What you have as > > some_func(X, Y) -> > %% Long bit of code > ...; > some_func(X, []) -> > %% More code > > could, as I proposed above, also be written > > some_func > (X,Y) -> %% long bit of code > ...; > (X,[]) -> %% More code > .... > > Why is this less readable to you? For the same reasons it is less readable to me. Readable code PROVIDES HELPS FOR THE READER. > You could answer, "Because it's not what I'm used to seeing in Erlang programs," but that begs the question. If people were more used to seeing the latter -- because making Erlang syntactically more self-consistent made it possible -- that argument wouldn't have much force -- except as an argument from pure conservatism. It seems to me that Michael Turner's argument is an argument from conservatism. Algol, Basic, COBOL, Fortran, PL/I, Simula, XPL, Java, Javascript, PHP, Perl, all of these languages write a function name once and only once at the beginning of a function. So therefore Erlang should do the same? Give me a break: those languages that "the majority of programmers" are familiar with don't *have* multiple clause functions. Let's take an example *adapted* from "Pattern Matching in Scheme". (define parse (match-lambda [(and s (? symbol?) (not ?lambda)) (make-Var s)] [(? number? n) (make-Const n)] [(?lambda args body) (make-Lam args (parse body))] [(f args ...) (make-App (parse f) (map parse args))] [x (error ?syntax "invalid expression")])) Now let's write that in Erlang: parse(S) when isatom(S), S \== lambda -> make_var(S); parse(N) when isnumber(N) -> make_const(N); parse([lambda,Args,Body]) -> make_lam(Args, parse(Body)); parse([F|Args]) -> make_app(parse(F), [parse(Arg) || Arg <- Args]); parse(_) -> error(syntax, <<"invalid expression">>). That paper ends with a page full of code defining a single function, and looking at it, I can see what pattern is being matched, but not why, and can't really tell without the aid of a ruler. I've played with things like that, and I never want to do so again. I greeted SML, then Haskell, and Erlang, with load cries of joy. > And this is entirely apart from "long bit of code" being a classic Smell anyway: > > http://www.soberit.hut.fi/mmantyla/BadCodeSmellsTaxonomy.htm > > -michael turner You will find that some of the things in that taxonomy are, um, expressed in an over-general way in the interests of brevity. For example, I don't see any reason to ban switch statements from Java. They don't do anything that dynamic dispatch can do, and dynamic dispatch doesn't do what switches can do. "Long Methods" is very much a matter of taste; how long is too long? I've just recommended to someone that they add about another 100 lines of code to a certain method today; 90 of those lines are a table of strings. There is nothing evil about a table of strings. From raimo+erlang-questions@REDACTED Fri May 20 10:11:19 2011 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Fri, 20 May 2011 10:11:19 +0200 Subject: [erlang-questions] 'reply-to' header in this mailing list In-Reply-To: References: <20110517142848.GA9263@erix.ericsson.se> <230D6DBF-EE90-475F-A973-DF0E7B71EF19@cs.otago.ac.nz> Message-ID: <20110520081119.GB27692@erix.ericsson.se> On Fri, May 20, 2011 at 08:35:28AM +0200, Mazen Harake wrote: > First thing I said heh. no one listened... :( > > Looking forward to having the same discussion in a few months time again :P Oh yes. Made me even consider putting 'reply-to' in the spam filter ;-) > > On 20 May 2011 05:01, Richard O'Keefe wrote: > > > I should like to point out that the *proposal* to change the > > currently very sensible behaviour of this list has *already* > > cost me far more time than any change would credibly save me. > > When you add up all the other people who've been following > > it, the waste of time is quite scary. > > > > IF YOU DON'T LIKE IT, LEARN TO USE THE "REPLY ALL" BUTTON > > ALL THE TIME. > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From ok@REDACTED Fri May 20 10:27:03 2011 From: ok@REDACTED (Richard O'Keefe) Date: Fri, 20 May 2011 20:27:03 +1200 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: Message-ID: <5F87F807-9E87-48A5-A238-C9C5904C5C39@cs.otago.ac.nz> On 19/05/2011, at 4:08 AM, Michael Turner wrote: > "Sorry, but Erlang doesn't *need* a better chance of survival." > > Now, wait, I'm really pretty sure that, less than a year ago, I saw both Peyton-Jones and Armstong in a video, speculating about the future of their respective favorite languages, and openly wondering what the long-term future held. And? Haskell is booming. They tried to avoid success and failed miserably. > In the meantime, I haven't noticed a dramatic increase in the frequency of Erlang job postings, though perhaps it's gone up. However, a doubling would still leave the number small. That does not mean that Erlang is under threat. Come to think of it, R is booming also. There are at least 81 mirrors of CRAN to handle the download volumes. How many R jobs do you see? > > "Changing core language features that are solid,..." > > Except that that what I proposes fixes a weak spot (among other things): failed syntactic consistency. No, it leaves the *weak* spot (the absence of names in funs) along and smashes the *strong* spot. > > "... well thought out ..." > > Except that Joe Armstrong has just admitted (on this thread, IIRC) that the reason for the inconsistency is that they just didn't think about it at the time...." If you mean when "funs" were introduced, that may be so. But the repeated function names were copied from languages where it *WAS* well thought out, rather like you probably would not fault someone for designing a programming language using [] for array subscripting. > > "... and non-harmful ..." > > Implying that what I suggest here IS harmful? Yes, it is It would seriously impair readability. It would break several code processing tools that I use. It would drastically impair the usefulness of every existing Erlang book. > > Actually not. No amount of education and experience will make repeating the function name with every clause a DRY issue, for those who find that repetition as more of an obstacle than otherwise. Remember always to consider the needs of READERS in preference to WRITERS. Take Haskell, as an example. One of the advantages of Haskell is that the types of functions can be inferred from their bodies (as long as you stick to the standard language and don't use the rank 2 extension GHC offers). Why then do most Haskell programmers recommend writing down function types anyway, even though that violates DRY? Because although the type *is* implicit in the code, and the *compiler* can figure it out, that doesn't mean it's easy for *humans*. If you are one of the people who find repeating function names an obstacle (on present evidence, a set of cardinality one), - you don't have to use Erlang - you can always write cases if you want - you could look into LFE - you could write your own preprocessor > No amount of education and experience will keep people from wondering, "Why this strange inconsistency?" As a matter of fact, I've known about Erlang since about a year (maybe two) since the first paper on it. Since well before it *had* funs, in fact. And you know, I've *never* had that thought. I don't experience any inconsistency. > oAnd better documentation and training will only make more people ask that question. I didn't ask that question until I *stumbled* on the extended syntax for funs; I didn't know about it before. "Extended syntax for funs?" What's that? The syntax of funs is described in chapter 7 of the reference manual, the chapter on expressions, which is exactly where you would expect to find it. The inconsistency I see is that functions are OK but funs (a) do not permit a visible function name -- just like Haskell, Clean, SML, CAML, &c (b) begin with "fun" instead of just beginning -- just like Haskell, Clean, SML, &c (c) end with "end" instead of ending with a "." -- the other languages I mentioned do not have any -- terminator, so I usually find myself having to -- wrap them in parentheses. It's quite nice not -- having to do that. However, (b) and (c) are unsurprising because funs are *expressions* and normal function definitions are not. If you are that upset about (a), I suggest that the inconsistency should be resolved by allowing funs to have names, as I've suggested, because that would fix the *other* difference between funs and normal functions, which is that normal functions can be directly recursive, and funs cannot. Your proposal to add a definition style that I find horrible for normal functions fails to do anything about that *other* difference between functions and funs. I repeat, you are urging that a *strong* spot be smashed to make it consistent with a *weak* spot, which is quite the wrong way around. From ok@REDACTED Fri May 20 10:29:49 2011 From: ok@REDACTED (Richard O'Keefe) Date: Fri, 20 May 2011 20:29:49 +1200 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: Message-ID: <01E59AE9-7861-4D6D-B7DB-1B87F8DF57C2@cs.otago.ac.nz> On 19/05/2011, at 4:17 AM, Daniel Goertzen wrote: > > I think this is a key issue here: multi-clause funs just don't happen all that often. It was very late in my Erlang learning experience that I found the need for multi-clause funs, and I easily found the documentation at the time. In fact the very first thing after the heading "7.17 Fun Expressions" is a sketch of a fun with multiple clauses. That's not what I call hard to find! From ok@REDACTED Fri May 20 10:36:00 2011 From: ok@REDACTED (Richard O'Keefe) Date: Fri, 20 May 2011 20:36:00 +1200 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: Message-ID: On 19/05/2011, at 4:21 AM, Michael Turner wrote: > "Anyway, it is often a good idea to break funs out into full functions to reduce nesting and facilitate tracing. Lots of funs make programs hard to debug." > > I agree. On both points. But neither point is really relevant to my case here. I'm not proposing that people write more funs. I'm proposing that writing named functions enjoy one of the syntactic benefits of funs. Don't you mean "costs", "prices", "curses", or something like that? In Haskell, my personal style book says "don't write anonymous functions, because you will never remember what they mean without a name." That works because - Haskell has list comprehensions, so a common need for anonymous functions in SML just goes away (Erlang has them too) - Haskell lets you nest ordinary functions one inside another If you want to snipe at Erlang syntax, complain about the fact that we cannot write f(...) -> let fun g(...) -> ...; g(...) -> ... end, fun h(...) -> ...; h(...) -> ... end in ... g(...) ... h(...) ... as an analogue of Haskell's f ... = ... g ... h ... where g ... = ... g ... = ... h ... = ... h ... = ... No, I am not proposing this or any other syntax for the purpose, just noting that where I would use a fun in Erlang, I *don't* use an anonymous function in Haskell, precisely so that I can give it a name. (And this is despite trying to use point-free style more.) From ok@REDACTED Fri May 20 10:40:38 2011 From: ok@REDACTED (Richard O'Keefe) Date: Fri, 20 May 2011 20:40:38 +1200 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: <1930B4D4-54DD-4F80-ACDE-BBE983315E64@hates.ms> Message-ID: <1799C0B6-EA5B-469E-94EE-18F3F3A16C52@cs.otago.ac.nz> On 19/05/2011, at 5:03 AM, Jack Moffitt wrote: >> I'm still waiting for the answer to the real showstopper question: would any >> existing code break, under my proposal? > > Assuming the answer is no, then I think it's fine to fix the > inconsistency an add this alternate notation. No, it's not fine. It fixes the WRONG END of the inconsistency. It's like saying "Ooh, these people have two legs and those people have one leg, the easiest thing to do is to cut one leg off those who have too." It harms readability in the eyes of a lot of people. Like I said, you would have to pay me big money to read code written in that style. It certainly breaks *my* pretty-printer and editor. Michael Turner is at perfect liberty to add any feature he likes to his copy of Erlang. He is at liberty to offer it to other people. > I'll also point out that this is name-less clause syntax is the same > as in Clojure: > > (defn > mymax > ([x] x) > ([x y] (if (> x y) x y)) > ([x y & more] > (reduce mymax (mymax x y) more))) And why do you think I don't use Clojure? From ok@REDACTED Fri May 20 10:43:55 2011 From: ok@REDACTED (Richard O'Keefe) Date: Fri, 20 May 2011 20:43:55 +1200 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: Message-ID: On 19/05/2011, at 9:40 AM, Joe Armstrong wrote: > One the subject of syntax there's another inconstancy that nobody seems to have noticed. All arguments in function calls *EXCEPT THE LAST* have commas after them. There's actually an EEP about commas in lists... From ok@REDACTED Fri May 20 11:09:32 2011 From: ok@REDACTED (Richard O'Keefe) Date: Fri, 20 May 2011 21:09:32 +1200 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: <4DD4D961.5000703@gmail.com> References: <2b09c525-84a1-4723-80a6-19615241934b@h7g2000yqa.googlegroups.com> <4DD4D59A.6080708@gmail.com> <4DD4D961.5000703@gmail.com> Message-ID: <5492B56E-644E-482D-91DB-8FECF14FBA46@cs.otago.ac.nz> On 19/05/2011, at 8:48 PM, Steve Davis wrote: > Out of interest, I tried it on one of my own modules. > > Your way: https://gist.github.com/980420 > The highway: https://github.com/komone/qrcode/blob/master/src/base32.erl > > In order to make your way less confusing, as the pattern matching entry points to the function were extremely un-obvious, and in the spirit of making it work I tried "double indent". > Double indented: https://gist.github.com/980412 > > For me, either way, the intention is harder to read, and/or forces me to focus on/put in a bunch of white space. If instead of encode0(<<>>, Acc) -> Acc; (<>, Acc) -> <>; (<>, Acc) -> <>; (<>, Acc) -> <>; (<>, Acc) -> <> ; (<>, Acc) -> <> ; (<>, Acc) -> <> ; (<>, Acc) -> < References: <4DD538E2.70107@gmail.com> Message-ID: On 20/05/2011, at 3:36 AM, Martin Dimitrov wrote: > Hi, > > How will we have to interpret this citation from "Erlang Programming" by > Francesco Cesarini and Simon Thompson (page 30): > > "All calls with variables in Erlang are call by value: all arguments to > a function call are evaluated before the body of the function is > evaluated. The concept of call by reference does not exist, ..." > > I know that variables are not copied when making a function call and are > copied when sending messages to processes. So why do the authors say all > calls are call by value? Aren't the function calls actually call by > reference? No. Here's call by reference: subroutine swap(x, y) real x, y, t t = x x = y y = t end program main real x, y x = 1.0 y = 2.0 call swap(x, y) print x, y end outputs 2, 1. Call by reference is where when you pass a variable to a procedure, it gets a reference to the variable, not the current value of the variable, and it can use that to change what the value of the variable is. It isn't that Erlang doesn't *copy* variables, but rather that it doesn't *have* variables in that sense. Now an Erlang *value* may be implemented as a pointer to a record in memory, but that implementation is NOT visible to an Erlang program. Erlang values could be implemented as strings "under the hood" and only the cost model would change, not what you can do. From ok@REDACTED Fri May 20 11:20:03 2011 From: ok@REDACTED (Richard O'Keefe) Date: Fri, 20 May 2011 21:20:03 +1200 Subject: [erlang-questions] call by value In-Reply-To: <20110519154040.GD23647@rabbitmq.com> References: <4DD538E2.70107@gmail.com> <20110519154040.GD23647@rabbitmq.com> Message-ID: <198BC9B8-53A4-4528-AF75-A06E70F36449@cs.otago.ac.nz> On 20/05/2011, at 3:40 AM, Matthew Sackman wrote: > Well I think there is a difference of interpretation of the terminology > based on whether you're in C world or functional world. To me, they're > more talking about laziness: Erlang is strict and as such expressions in > arguments to function calls are reduced to terms before the function is > invoked. I'm not sure that's exactly the same as call by value, "strict" argument evaluation is precisely call by value. The terminology used in the original quotation was that of the C++ world (and others), where void foo(int &x) {...} ... foo(y) ... passes the *address* of the mutable variable y to foo so that foo may change it, whereas void bar(int x) {...} ... foo(y) ... passes the *contents* of the mutable value y to foo. From ok@REDACTED Fri May 20 11:22:40 2011 From: ok@REDACTED (Richard O'Keefe) Date: Fri, 20 May 2011 21:22:40 +1200 Subject: [erlang-questions] call by value In-Reply-To: References: <4DD538E2.70107@gmail.com> Message-ID: <73A06613-DA9B-4747-9914-80D1F1BB78DB@cs.otago.ac.nz> On 20/05/2011, at 4:23 AM, Jesper Louis Andersen wrote: > On Thu, May 19, 2011 at 17:36, Martin Dimitrov wrote: > >> "All calls with variables in Erlang are call by value: all arguments to >> a function call are evaluated before the body of the function is >> evaluated. The concept of call by reference does not exist, ..." > > I'll reply even though others have replied and add a bit more flesh. > Suppose we have a function: > > f(X) -> > X + 7. > > and we want to call it like this: > > f(3 + 5), > > now there are two ways the reduction can proceed. Either we first > evaluate the expression and then make the call, > > f(3 + 5) ==> f(8) ==> 8 + 7 ==> 15 > > which is the call-by-value evaluation strategy, or we do it by > substituting in the expression first, > > f(3 + 5) ==> (3 + 5) + 7 ==> 8 + 7 ==> 15 That is *NOT* call by reference. It is call by *NAME*, which is quite difference. (The Algol 60 committee intended to specify call by reference, but used the "copy rule" to define it, which to their dismay specified call by name instead.) Pascal 'var' parameters are call by reference, not by name.\ From mazen.harake@REDACTED Fri May 20 11:25:27 2011 From: mazen.harake@REDACTED (Mazen Harake) Date: Fri, 20 May 2011 11:25:27 +0200 Subject: [erlang-questions] supervisor started from gen_server In-Reply-To: <20110518121242.GG7320@aluminum.local> References: <20110518121242.GG7320@aluminum.local> Message-ID: I don't agree with the "never" part. There are corner cases and I would, in general, absolutely agree with what you wrote but here is one example of an exception. In my IRC library (https://github.com/mazenharake/eirc) I have the following scenario: One can create 1..n clients. Each client is a process (running a gen_server in eirc_cl.erl). A client can have many processes associated with it, in my case these are called Bots. Each bot is started and supervised by a client. A bot shall not terminate unless told to do so (gracefully) or if the parent dies (i.e the client). Now if I manually start a supervisor instance inside the gen_server I can simply make use of the supervisor functionality without handling any of that in my gen_server. I can add and remove children (bots) dynamically from my supervisor I.e. I don't have to maintain my own list of them and when I (the client) exits my children (I.e. the supervisor) will exit and thus my bots will exit... all according to OTP principals and I don't need to catch exit signals. This makes it REALLY easy to clean up things since all I have to do is to close the client process, the client process doesn't even need logic in the terminate callback since the children will exit with the same reason. If my supervisor was "on the outside" (like you suggest and which it normally is) I would have to make sure to clean up after myself with the supervisor. So it is much simpler (from an isolation point of view) to (in my case) start a supervisor Inside the gen_server. never say never ;) /M On 18 May 2011 14:13, Vance Shipley wrote: > On Wed, May 18, 2011 at 11:38:50AM +0200, Roberto Ostinelli wrote: > } just a quick question: can you think of any case in which starting a > } supervisor from a gen_server would actually be a perfectly fit idea? > > Never. > > +---------+ > | foo_sup | > +-+-----+-+ > / \ > +----------+--+ +--+---------+ > | bar_sup_sup | | foo_server | > +---+---------+ +------------+ > | > +----+----+ > | bar_sup | > +---------+ > > Start a supervisor for the new dynamic supervisor(s) and use > supervisor:start_child/2 from the gen_server to start it. > > -- > -Vance > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Fri May 20 11:44:03 2011 From: ok@REDACTED (Richard O'Keefe) Date: Fri, 20 May 2011 21:44:03 +1200 Subject: [erlang-questions] call by value In-Reply-To: <4DD56A76.1050303@gmail.com> References: <4DD538E2.70107@gmail.com> <4DD56A76.1050303@gmail.com> Message-ID: <5EEE88DE-75FD-4452-B981-FB47C8FD8A93@cs.otago.ac.nz> On 20/05/2011, at 7:07 AM, Martin Dimitrov wrote: > Thanks for the explanation. Now I am glad I asked that question. > > I had always thought of call-by-value as the actual act of copying the > value which now I understand it might be or might not be as in the case > with Erlang. It's precisely the same in Java, Javascript, C#, Eiffel, Lisp, you name it (except for Pascal). PASSING a value is a constant time operation; for small integers this might be equivalent to copying, but for "values" that are (references to) linked structures, no copying is done. The way Java talks about it, if you pass an array to a method, the *object reference* is the value that is passed, and this happens to point to a shared mutable object which is *not* copied. From ok@REDACTED Fri May 20 12:04:56 2011 From: ok@REDACTED (Richard O'Keefe) Date: Fri, 20 May 2011 22:04:56 +1200 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: <661C1ED1-0683-435C-8BF0-5EAB2289D546@erlang-solutions.com> Message-ID: <73FD1684-4D13-40E1-8CE6-7CFE266AB382@cs.otago.ac.nz> On 20/05/2011, at 5:29 PM, Michael Turner wrote: > "- it's not faster (compile time, might even make compiling slower)" > > You've got to be kidding. It's long been known: the time complexity of parsing is overwhelmingly dominated by scanning. Code written in the form I propose would have fewer tokens to scan. That used to be true. However, it's not clear that it _is_ true when the parser is written in Yecc, as the Erlang parser is. And it's not terribly important anyway, because in the compilers I know anything about, the cost of scanning AND parsing put together is less than half the total time. (For example, one body of code that I work with is parsed and semantic checked in under a second, but takes about 90 seconds for code generation.) I just wrote a parser for someone else's scripting language last week. Scanning took less time than parsing, and the only reason code generation doesn't dominate both is that it doesn't do any. > > "- it doesn't make the parser code easier to maintain" > > It might, actually. See above. If both the existing readable alternative and the proposed horrible one are supported, the code *has* to increase in volume, and *has* to become less maintainable. > > "- it's making a lot of documentation obsolete that will need to be updated. This is common to all changes though." > > Yes, it is. Not to mention that the documentation on Erlang syntax is due for an upgrade anyway. The first hit I get on "Erlang" and "fun" yields the section "Syntax of funs", here: > > http://www.erlang.org/doc/programming_examples/funs.html#id59209 > > Yes, believe it: no coverage of the multi-clause case. Yes, because THAT IS COVERED IN THE REFERENCE MANUAL WHERE THE VERY FIRST THING AFTER THE SECTION HEADING SHOWS A MULTICLAUSE FUN. 1. You want to learn about syntax? Check the reference manual. 2. You want to learn about something that goes in expressions? Check the expressions chapter. 3. You want to learn about a particular kind of form? Check the table of contents for that chapter. 4. See 'fun expressions'? Click on it. And there you are. If you deliberately don't look in the reference manual, it's not the fault of Erlang or its documenters. There are plenty of things to improve, but before complaining about the syntax, people really do have an obligation to look in the most obvious place. > "Oh and lastly, you could also have to consider this ambiguity ...." > > It wouldn't even be an ambiguity. It would only be a weird and pointless way to write that code. And omitting the function name _anywhere_ in the first place is a weird and pointless way to write code. You are attacking one of the features of Erlang that I have found most helpful. From ok@REDACTED Fri May 20 12:15:09 2011 From: ok@REDACTED (Richard O'Keefe) Date: Fri, 20 May 2011 22:15:09 +1200 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: <1DB4D10E-B83D-4E69-8888-18CE552DC785@erlang-solutions.com> References: <1930B4D4-54DD-4F80-ACDE-BBE983315E64@hates.ms> <20110519093746.GB27904@erix.ericsson.se> <7418517D-4A84-4F44-94E8-B15045F5DAC0@erlang-solutions.com> <1DB4D10E-B83D-4E69-8888-18CE552DC785@erlang-solutions.com> Message-ID: <1D408305-A34B-4931-A11F-9E6477F01F43@cs.otago.ac.nz> On 20/05/2011, at 11:20 AM, Fr?d?ric Trottier-H?bert wrote: > I don't agree with complaints either -- I have no issue with Erlang's syntax, lisp/scheme/racket's syntax or any other language. The reality, however, is that while programmers can pick up Erlang's syntax quickly, there's still an initial struggle to break what has been committed to muscle memory by many of the people I have taught it to. Perhaps the biggest obstacle might be that = does not mean assignment, or else that alphabetic case *does* matter but cannot be chosen freely. Neither of which is something I'd change. From vasdeveloper@REDACTED Fri May 20 12:15:19 2011 From: vasdeveloper@REDACTED (Kannan) Date: Fri, 20 May 2011 15:45:19 +0530 Subject: [erlang-questions] Efficiency of a list construction Message-ID: Hi Is the following list construction an efficient one? flush() -> receive Msg -> [Msg|flush()] after 17 -> [] end. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vances@REDACTED Fri May 20 12:50:46 2011 From: vances@REDACTED (Vance Shipley) Date: Fri, 20 May 2011 16:20:46 +0530 Subject: [erlang-questions] Efficiency of a list construction In-Reply-To: References: Message-ID: <20110520105035.GK11339@aluminum.local> Kannan, No, it is not tail recursive. This is: %% @spec() -> [term()] %% flush() -> flush([]). %% @hidden flush(Msgs) -> receive Msg -> flush([Msg | Msgs]); after 17 -> Msgs end. On Fri, May 20, 2011 at 03:45:19PM +0530, Kannan wrote: } Is the following list construction an efficient one? } } flush() -> } receive } Msg -> } [Msg|flush()] } after 17 -> } [] } end. -- -Vance From paul.james.barry@REDACTED Fri May 20 13:08:02 2011 From: paul.james.barry@REDACTED (Paul Barry) Date: Fri, 20 May 2011 12:08:02 +0100 Subject: [erlang-questions] Efficiency of a list construction In-Reply-To: <20110520105035.GK11339@aluminum.local> References: <20110520105035.GK11339@aluminum.local> Message-ID: Interesting response. I'm currently working my way through both Joe's book and Francesco/Simon's. As this is Erlang, I'm reading the two books in parallel (of course). Both books talk about the efficiency of tail recursion over direct recursion with a bit of talk about how the run-time may optimize for code that isn't tail recursive to improve its performance. The suggestion seems to be that in older versions of the run-time, tail recursion won hands down, but that nowadays this may not always be the case. Is there an update on this? Of course, Joe's book suggests that the only way to *really* know is to measure (good advice). Using "timer:tc" (as described on page 107 of the Francesco/Simon book) might be a good place to start. Regards. Paul. On 20 May 2011 11:50, Vance Shipley wrote: > Kannan, > > No, it is not tail recursive. ?This is: > > ? ? %% @spec() -> [term()] > ? ? %% > ? ? flush() -> > ? ? ? ?flush([]). > > ? ? %% @hidden > ? ? flush(Msgs) -> > ? ? ? ?receive > ? ? ? ? ? ? ? ?Msg -> > ? ? ? ? ? ? ? ? ? ? ? ?flush([Msg | Msgs]); > ? ? ? ?after 17 -> > ? ? ? ? ? ? ? ?Msgs > ? ? ? ?end. > > On Fri, May 20, 2011 at 03:45:19PM +0530, Kannan wrote: > } ?Is the following list construction an efficient one? > } > } ?flush() -> > } ? ? ?receive > } ?Msg -> > } ? ? ?[Msg|flush()] > } ? ? ?after 17 -> > } ? ? ?[] > } ? ? ?end. > > -- > ? ? ? ?-Vance > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Paul Barry, w: http://paulbarry.itcarlow.ie, e: paul.barry@REDACTED Lecturer, Computer Networking: Institute of Technology, Carlow, Ireland. From ulf.wiger@REDACTED Fri May 20 13:11:58 2011 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Fri, 20 May 2011 13:11:58 +0200 Subject: [erlang-questions] Efficiency of a list construction In-Reply-To: References: <20110520105035.GK11339@aluminum.local> Message-ID: <8B04372C-8D89-451E-A9A9-18B431BCB1A2@erlang-solutions.com> On 20 May 2011, at 13:08, Paul Barry wrote: > Both books talk about the efficiency of tail recursion over direct > recursion with a bit of talk about how the run-time may optimize for > code that isn't tail recursive to improve its performance. The > suggestion seems to be that in older versions of the run-time, tail > recursion won hands down, but that nowadays this may not always be the > case. Is there an update on this? The Erlang/OTP Efficiency Guide is the most up-to-date document on the matter. E.g. Chapter 5.4 - Why you should not worry about recursive lists functions http://www.erlang.org/doc/efficiency_guide/listHandling.html#id64754 BR, Ulf W Ulf Wiger, CTO, Erlang Solutions, Ltd. http://erlang-solutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From vasdeveloper@REDACTED Fri May 20 13:28:43 2011 From: vasdeveloper@REDACTED (Kannan) Date: Fri, 20 May 2011 16:58:43 +0530 Subject: [erlang-questions] Efficiency of a list construction In-Reply-To: <20110520105035.GK11339@aluminum.local> References: <20110520105035.GK11339@aluminum.local> Message-ID: I saw this function in gen_sctp_SUITE.erl :-( On Fri, May 20, 2011 at 4:20 PM, Vance Shipley wrote: > Kannan, > > No, it is not tail recursive. This is: > > %% @spec() -> [term()] > %% > flush() -> > flush([]). > > %% @hidden > flush(Msgs) -> > receive > Msg -> > flush([Msg | Msgs]); > after 17 -> > Msgs > end. > > On Fri, May 20, 2011 at 03:45:19PM +0530, Kannan wrote: > } Is the following list construction an efficient one? > } > } flush() -> > } receive > } Msg -> > } [Msg|flush()] > } after 17 -> > } [] > } end. > > -- > -Vance > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lenartlad@REDACTED Fri May 20 13:30:16 2011 From: lenartlad@REDACTED (Ladislav Lenart) Date: Fri, 20 May 2011 13:30:16 +0200 Subject: [erlang-questions] Efficiency of a list construction In-Reply-To: References: <20110520105035.GK11339@aluminum.local> Message-ID: <4DD650C8.5020101@volny.cz> Hello. I would like to point out that the two implementations are not exactly the same because the tail recursive version returns messages in the reverse order as opposed to the original (non-tail recursive version), which does preserve the order of received messages. The equivalent tail-recursive implementation would be: %% @spec() -> [term()] flush() -> flush([]). %% @hidden flush(Msgs) -> receive Msg -> flush([Msg | Msgs]); after 17 -> lists:reverse(Msgs) % added call to lists:reverse/1 end. However if the order is important I would use the original non-tail recursive version. For example lists:map/2 uses non-tail recursive approach as well. Ladislav Lenart On 20.5.2011 13:08, Paul Barry wrote: > Interesting response. > > I'm currently working my way through both Joe's book and > Francesco/Simon's. As this is Erlang, I'm reading the two books in > parallel (of course). > > Both books talk about the efficiency of tail recursion over direct > recursion with a bit of talk about how the run-time may optimize for > code that isn't tail recursive to improve its performance. The > suggestion seems to be that in older versions of the run-time, tail > recursion won hands down, but that nowadays this may not always be the > case. Is there an update on this? > > Of course, Joe's book suggests that the only way to *really* know is > to measure (good advice). Using "timer:tc" (as described on page 107 > of the Francesco/Simon book) might be a good place to start. > > Regards. > > Paul. > > > On 20 May 2011 11:50, Vance Shipley wrote: >> Kannan, >> >> No, it is not tail recursive. This is: >> >> %% @spec() -> [term()] >> %% >> flush() -> >> flush([]). >> >> %% @hidden >> flush(Msgs) -> >> receive >> Msg -> >> flush([Msg | Msgs]); >> after 17 -> >> Msgs >> end. >> >> On Fri, May 20, 2011 at 03:45:19PM +0530, Kannan wrote: >> } Is the following list construction an efficient one? >> } >> } flush() -> >> } receive >> } Msg -> >> } [Msg|flush()] >> } after 17 -> >> } [] >> } end. >> >> -- >> -Vance >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > > From jameschurchman@REDACTED Fri May 20 13:35:13 2011 From: jameschurchman@REDACTED (James Churchman) Date: Fri, 20 May 2011 12:35:13 +0100 Subject: [erlang-questions] Advanced Erlang Subtleties In-Reply-To: <20110520034535.GA6320@mulga.csse.unimelb.edu.au> References: <20110520034535.GA6320@mulga.csse.unimelb.edu.au> Message-ID: > Indeed. If we can have only one built-in comparison, it needs to be > total over all values. It is a pity that Prolog's distinction between > term comparison and number comparison wasn't carried over to Erlang :-( > > Indeed that would have made the language a tad bigger, but stopped this ambiguity! Are there any other good subtleties to erlang that anybody wishes to add to this list? I can't have covered all of them :-) also does anybody know the answer to my : > There is a 3rd parameter in the AST for a catch section in a Try/Catch that is always a match all ( a bit like ERROR_TYPE:ERROR:_ ) does anybody know what this means? is there an extra option in a catch that is rarely used? James On 20 May 2011 04:45, Jeff Schultz wrote: > On Thu, May 19, 2011 at 11:02:35PM +0200, Joe Armstrong wrote: > > > I can see the equivalent evaluation of "250"<250 being a common > mistake, > > > and always being false is hardly useful. > > > A "<" B when A and B have different types means A is > > "less complex" than B. Lists and more complex than integers > > "250" is a list so "250"<250 is false. > > > Suppose I want to make a Key-Value database, where the Key can be > anything, > > including 250 and "250" to make any form of ordered tree we need a total > > order over all the keys. > > Indeed. If we can have only one built-in comparison, it needs to be > total over all values. It is a pity that Prolog's distinction between > term comparison and number comparison wasn't carried over to Erlang :-( > > > Jeff Schultz > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vances@REDACTED Fri May 20 13:44:46 2011 From: vances@REDACTED (Vance Shipley) Date: Fri, 20 May 2011 17:14:46 +0530 Subject: [erlang-questions] Efficiency of a list construction In-Reply-To: <8B04372C-8D89-451E-A9A9-18B431BCB1A2@erlang-solutions.com> References: <20110520105035.GK11339@aluminum.local> <8B04372C-8D89-451E-A9A9-18B431BCB1A2@erlang-solutions.com> Message-ID: <20110520114443.GL11339@aluminum.local> Old habits die hard. On Fri, May 20, 2011 at 01:11:58PM +0200, Ulf Wiger wrote: } E.g. Chapter 5.4 - Why you should not worry about recursive lists functions } } http://www.erlang.org/doc/efficiency_guide/listHandling.html#id64754 -- -Vance From fred.hebert@REDACTED Fri May 20 13:47:15 2011 From: fred.hebert@REDACTED (=?iso-8859-1?Q?Fr=E9d=E9ric_Trottier-H=E9bert?=) Date: Fri, 20 May 2011 07:47:15 -0400 Subject: [erlang-questions] Efficiency of a list construction In-Reply-To: <20110520105035.GK11339@aluminum.local> References: <20110520105035.GK11339@aluminum.local> Message-ID: <8E910913-40E2-4C0D-B375-985D72E7FDAF@erlang-solutions.com> I would dare say that tail recursion is not exactly important in this example. In both cases, you basically end up creating a list, which will hold all the values of all messages. In one case, you will be creating a list of N elements to be carried on the stack, in the other case, you'll be having a stack that is about the size of N elements. In the first case, you also have to reverse the list, in the other, you don't. It's not really a big deal IMO to use a call that is not tail recursive when what you are doing is building a list that is in the same order as the items happen. If you look into the stdlib, you'll see that the lists:map/2 function is (or was? haven't looked in a few versions) implemented in a non tail recursive manner. When you think of it, it kind of makes sense too; you give a list of the same size as before, in the right order, for similar speeds, and you'll be avoiding a call to a BIF (reverse/1) on top of it. Now, in the case when you're building a list in a different order or where you basically create more data than necessary by avoiding recursion (ex.: a tail recursive fibonacci vs. a non tail recursive fibonacci), then tail recursion should be chosen, but I see nothing wrong with the flush/0 implementation of Kannan. -- Fred H?bert http://www.erlang-solutions.com On 2011-05-20, at 06:50 AM, Vance Shipley wrote: > Kannan, > > No, it is not tail recursive. This is: > > %% @spec() -> [term()] > %% > flush() -> > flush([]). > > %% @hidden > flush(Msgs) -> > receive > Msg -> > flush([Msg | Msgs]); > after 17 -> > Msgs > end. > > On Fri, May 20, 2011 at 03:45:19PM +0530, Kannan wrote: > } Is the following list construction an efficient one? > } > } flush() -> > } receive > } Msg -> > } [Msg|flush()] > } after 17 -> > } [] > } end. > > -- > -Vance > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From olopierpa@REDACTED Fri May 20 13:50:50 2011 From: olopierpa@REDACTED (Pierpaolo Bernardi) Date: Fri, 20 May 2011 13:50:50 +0200 Subject: [erlang-questions] Efficiency of a list construction In-Reply-To: <20110520105035.GK11339@aluminum.local> References: <20110520105035.GK11339@aluminum.local> Message-ID: On Fri, May 20, 2011 at 12:50, Vance Shipley wrote: > Kannan, > > No, it is not tail recursive. ?This is: > > ? ? %% @spec() -> [term()] > ? ? %% > ? ? flush() -> > ? ? ? ?flush([]). > > ? ? %% @hidden > ? ? flush(Msgs) -> > ? ? ? ?receive > ? ? ? ? ? ? ? ?Msg -> > ? ? ? ? ? ? ? ? ? ? ? ?flush([Msg | Msgs]); > ? ? ? ?after 17 -> > ? ? ? ? ? ? ? ?Msgs > ? ? ? ?end. However, this returns a reversed list, w.r.t. > On Fri, May 20, 2011 at 03:45:19PM +0530, Kannan wrote: > } ?Is the following list construction an efficient one? > } > } ?flush() -> > } ? ? ?receive > } ?Msg -> > } ? ? ?[Msg|flush()] > } ? ? ?after 17 -> > } ? ? ?[] > } ? ? ?end. P. From vasdeveloper@REDACTED Fri May 20 13:52:54 2011 From: vasdeveloper@REDACTED (Kannan) Date: Fri, 20 May 2011 17:22:54 +0530 Subject: [erlang-questions] supervisor started from gen_server In-Reply-To: References: <20110518121242.GG7320@aluminum.local> Message-ID: Mazen, You can do the same thing with simple_one_for_one supervisors, one_for_all supervisors and one_for_one supervisors stacked in different levels. On Fri, May 20, 2011 at 2:55 PM, Mazen Harake wrote: > I don't agree with the "never" part. There are corner cases and I would, in > general, absolutely agree with what you wrote but here is one example of an > exception. > > In my IRC library (https://github.com/mazenharake/eirc) I have the > following scenario: > > One can create 1..n clients. Each client is a process (running a gen_server > in eirc_cl.erl). A client can have many processes associated with it, in my > case these are called Bots. Each bot is started and supervised by a client. > A bot shall not terminate unless told to do so (gracefully) or if the parent > dies (i.e the client). Now if I manually start a supervisor instance inside > the gen_server I can simply make use of the supervisor functionality without > handling any of that in my gen_server. I can add and remove children (bots) > dynamically from my supervisor I.e. I don't have to maintain my own list of > them and when I (the client) exits my children (I.e. the supervisor) will > exit and thus my bots will exit... all according to OTP principals and I > don't need to catch exit signals. This makes it REALLY easy to clean up > things since all I have to do is to close the client process, the client > process doesn't even need logic in the terminate callback since the children > will exit with the same reason. If my supervisor was "on the outside" (like > you suggest and which it normally is) I would have to make sure to clean up > after myself with the supervisor. > > So it is much simpler (from an isolation point of view) to (in my case) > start a supervisor Inside the gen_server. > > never say never ;) > > /M > > > > > > On 18 May 2011 14:13, Vance Shipley wrote: > >> On Wed, May 18, 2011 at 11:38:50AM +0200, Roberto Ostinelli wrote: >> } just a quick question: can you think of any case in which starting a >> } supervisor from a gen_server would actually be a perfectly fit idea? >> >> Never. >> >> +---------+ >> | foo_sup | >> +-+-----+-+ >> / \ >> +----------+--+ +--+---------+ >> | bar_sup_sup | | foo_server | >> +---+---------+ +------------+ >> | >> +----+----+ >> | bar_sup | >> +---------+ >> >> Start a supervisor for the new dynamic supervisor(s) and use >> supervisor:start_child/2 from the gen_server to start it. >> >> -- >> -Vance >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.schubert@REDACTED Fri May 20 13:53:01 2011 From: max.schubert@REDACTED (Max Schubert) Date: Fri, 20 May 2011 07:53:01 -0400 Subject: [erlang-questions] 'reply-to' header in this mailing list In-Reply-To: <20110520081119.GB27692@erix.ericsson.se> References: <20110517142848.GA9263@erix.ericsson.se> <230D6DBF-EE90-475F-A973-DF0E7B71EF19@cs.otago.ac.nz> <20110520081119.GB27692@erix.ericsson.se> Message-ID: The Ruby on Rails lists have both a web-based forum and forum-to-email gateway - users can choose to use either interface to create and respond to questions and responses made using either interface are seen on both interfaces as well. Max On 5/20/11, Raimo Niskanen wrote: > On Fri, May 20, 2011 at 08:35:28AM +0200, Mazen Harake wrote: >> First thing I said heh. no one listened... :( >> >> Looking forward to having the same discussion in a few months time again >> :P > > Oh yes. Made me even consider putting 'reply-to' in the spam filter ;-) > >> >> On 20 May 2011 05:01, Richard O'Keefe wrote: >> >> > I should like to point out that the *proposal* to change the >> > currently very sensible behaviour of this list has *already* >> > cost me far more time than any change would credibly save me. >> > When you add up all the other people who've been following >> > it, the waste of time is quite scary. >> > >> > IF YOU DON'T LIKE IT, LEARN TO USE THE "REPLY ALL" BUTTON >> > ALL THE TIME. >> > >> > >> > _______________________________________________ >> > erlang-questions mailing list >> > erlang-questions@REDACTED >> > http://erlang.org/mailman/listinfo/erlang-questions >> > > >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > > -- > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From mrtndimitrov@REDACTED Fri May 20 13:59:11 2011 From: mrtndimitrov@REDACTED (Martin Dimitrov) Date: Fri, 20 May 2011 14:59:11 +0300 Subject: [erlang-questions] call by value In-Reply-To: <5EEE88DE-75FD-4452-B981-FB47C8FD8A93@cs.otago.ac.nz> References: <4DD538E2.70107@gmail.com> <4DD56A76.1050303@gmail.com> <5EEE88DE-75FD-4452-B981-FB47C8FD8A93@cs.otago.ac.nz> Message-ID: <4DD6578F.7040105@gmail.com> > but for "values" that are (references to) linked structures, > no copying is done. > If you are talking about Java, isn't this copy-by-reference? From mazen.harake@REDACTED Fri May 20 14:00:16 2011 From: mazen.harake@REDACTED (Mazen Harake) Date: Fri, 20 May 2011 14:00:16 +0200 Subject: [erlang-questions] supervisor started from gen_server In-Reply-To: References: <20110518121242.GG7320@aluminum.local> Message-ID: Of course you *can* but the point I'm trying to make is that it's not "wrong" to do it like I did and it doesn't break OTP behaviour and is actually convenient. Doing it like I did eliminates all the clean up code I have to make when starting and stopping when the supervisor is "parallel" rather than "under" my client process. As I said, in general you wouldn't want to do it like that but you *can* and it isn't *wrong* and it isn't a *hack*. The Erlang documentation doesn't (AFAIK) bring up this scenario but it doesn't make it less useful. That is all. On 20 May 2011 13:52, Kannan wrote: > Mazen, > > You can do the same thing with simple_one_for_one supervisors, one_for_all > supervisors and one_for_one supervisors stacked in different levels. > > > > > > On Fri, May 20, 2011 at 2:55 PM, Mazen Harake wrote: > >> I don't agree with the "never" part. There are corner cases and I would, >> in general, absolutely agree with what you wrote but here is one example of >> an exception. >> >> In my IRC library (https://github.com/mazenharake/eirc) I have the >> following scenario: >> >> One can create 1..n clients. Each client is a process (running a >> gen_server in eirc_cl.erl). A client can have many processes associated with >> it, in my case these are called Bots. Each bot is started and supervised by >> a client. A bot shall not terminate unless told to do so (gracefully) or if >> the parent dies (i.e the client). Now if I manually start a supervisor >> instance inside the gen_server I can simply make use of the supervisor >> functionality without handling any of that in my gen_server. I can add and >> remove children (bots) dynamically from my supervisor I.e. I don't have to >> maintain my own list of them and when I (the client) exits my children (I.e. >> the supervisor) will exit and thus my bots will exit... all according to OTP >> principals and I don't need to catch exit signals. This makes it REALLY easy >> to clean up things since all I have to do is to close the client process, >> the client process doesn't even need logic in the terminate callback since >> the children will exit with the same reason. If my supervisor was "on the >> outside" (like you suggest and which it normally is) I would have to make >> sure to clean up after myself with the supervisor. >> >> So it is much simpler (from an isolation point of view) to (in my case) >> start a supervisor Inside the gen_server. >> >> never say never ;) >> >> /M >> >> >> >> >> >> On 18 May 2011 14:13, Vance Shipley wrote: >> >>> On Wed, May 18, 2011 at 11:38:50AM +0200, Roberto Ostinelli wrote: >>> } just a quick question: can you think of any case in which starting a >>> } supervisor from a gen_server would actually be a perfectly fit idea? >>> >>> Never. >>> >>> +---------+ >>> | foo_sup | >>> +-+-----+-+ >>> / \ >>> +----------+--+ +--+---------+ >>> | bar_sup_sup | | foo_server | >>> +---+---------+ +------------+ >>> | >>> +----+----+ >>> | bar_sup | >>> +---------+ >>> >>> Start a supervisor for the new dynamic supervisor(s) and use >>> supervisor:start_child/2 from the gen_server to start it. >>> >>> -- >>> -Vance >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrtndimitrov@REDACTED Fri May 20 14:11:49 2011 From: mrtndimitrov@REDACTED (Martin Dimitrov) Date: Fri, 20 May 2011 15:11:49 +0300 Subject: [erlang-questions] erlmail problems Message-ID: <4DD65A85.5000605@gmail.com> Hi, I am trying to use erlmail as an IMAP client only. I modified the library to use ssl instead of gen_tcp sockets but I receive errors when the library is parsing the return line from googlemail: * OK Gimap ready for requests from 79.126.56.221 i9if507573yhn.157\r\n This line seems to me ok. Had anyone used erlmail as an IMAP client? Any advise? Other libraries? Regards, Martin From spawn.think@REDACTED Fri May 20 14:19:05 2011 From: spawn.think@REDACTED (Ahmed Omar) Date: Fri, 20 May 2011 14:19:05 +0200 Subject: [erlang-questions] supervisor started from gen_server In-Reply-To: References: <20110518121242.GG7320@aluminum.local> Message-ID: Hi Mazen , One question rises here about this. What happens when the processes under that supervisor reach the maximum number of restarts, and the supervisor is terminated. In a "traditional" supervision tree, the higher level supervisor shall react to that. In your case, it will be the gen_server which i imagine will crash then? On Fri, May 20, 2011 at 2:00 PM, Mazen Harake wrote: > Of course you *can* but the point I'm trying to make is that it's not > "wrong" to do it like I did and it doesn't break OTP behaviour and is > actually convenient. Doing it like I did eliminates all the clean up code I > have to make when starting and stopping when the supervisor is "parallel" > rather than "under" my client process. > > As I said, in general you wouldn't want to do it like that but you *can* > and it isn't *wrong* and it isn't a *hack*. The Erlang documentation doesn't > (AFAIK) bring up this scenario but it doesn't make it less useful. > > That is all. > > > On 20 May 2011 13:52, Kannan wrote: > >> Mazen, >> >> You can do the same thing with simple_one_for_one supervisors, one_for_all >> supervisors and one_for_one supervisors stacked in different levels. >> >> >> >> >> >> On Fri, May 20, 2011 at 2:55 PM, Mazen Harake wrote: >> >>> I don't agree with the "never" part. There are corner cases and I would, >>> in general, absolutely agree with what you wrote but here is one example of >>> an exception. >>> >>> In my IRC library (https://github.com/mazenharake/eirc) I have the >>> following scenario: >>> >>> One can create 1..n clients. Each client is a process (running a >>> gen_server in eirc_cl.erl). A client can have many processes associated with >>> it, in my case these are called Bots. Each bot is started and supervised by >>> a client. A bot shall not terminate unless told to do so (gracefully) or if >>> the parent dies (i.e the client). Now if I manually start a supervisor >>> instance inside the gen_server I can simply make use of the supervisor >>> functionality without handling any of that in my gen_server. I can add and >>> remove children (bots) dynamically from my supervisor I.e. I don't have to >>> maintain my own list of them and when I (the client) exits my children (I.e. >>> the supervisor) will exit and thus my bots will exit... all according to OTP >>> principals and I don't need to catch exit signals. This makes it REALLY easy >>> to clean up things since all I have to do is to close the client process, >>> the client process doesn't even need logic in the terminate callback since >>> the children will exit with the same reason. If my supervisor was "on the >>> outside" (like you suggest and which it normally is) I would have to make >>> sure to clean up after myself with the supervisor. >>> >>> So it is much simpler (from an isolation point of view) to (in my case) >>> start a supervisor Inside the gen_server. >>> >>> never say never ;) >>> >>> /M >>> >>> >>> >>> >>> >>> On 18 May 2011 14:13, Vance Shipley wrote: >>> >>>> On Wed, May 18, 2011 at 11:38:50AM +0200, Roberto Ostinelli wrote: >>>> } just a quick question: can you think of any case in which starting a >>>> } supervisor from a gen_server would actually be a perfectly fit idea? >>>> >>>> Never. >>>> >>>> +---------+ >>>> | foo_sup | >>>> +-+-----+-+ >>>> / \ >>>> +----------+--+ +--+---------+ >>>> | bar_sup_sup | | foo_server | >>>> +---+---------+ +------------+ >>>> | >>>> +----+----+ >>>> | bar_sup | >>>> +---------+ >>>> >>>> Start a supervisor for the new dynamic supervisor(s) and use >>>> supervisor:start_child/2 from the gen_server to start it. >>>> >>>> -- >>>> -Vance >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think -------------- next part -------------- An HTML attachment was scrubbed... URL: From mazen.harake@REDACTED Fri May 20 14:23:08 2011 From: mazen.harake@REDACTED (Mazen Harake) Date: Fri, 20 May 2011 14:23:08 +0200 Subject: [erlang-questions] supervisor started from gen_server In-Reply-To: References: <20110518121242.GG7320@aluminum.local> Message-ID: Correct. A Bot (in this case) is seen as an extension of the client. Thus if the bot (which by implication is the client) is misbehaving or enters a faulty state the client crashes. The result of this is that the client is restarted (and the corresponding bots are reset). /M On 20 May 2011 14:19, Ahmed Omar wrote: > Hi Mazen , > > One question rises here about this. What happens when the processes under > that supervisor reach the maximum number of restarts, and the supervisor is > terminated. In a "traditional" supervision tree, the higher level supervisor > shall react to that. In your case, it will be the gen_server which i imagine > will crash then? > > On Fri, May 20, 2011 at 2:00 PM, Mazen Harake wrote: > >> Of course you *can* but the point I'm trying to make is that it's not >> "wrong" to do it like I did and it doesn't break OTP behaviour and is >> actually convenient. Doing it like I did eliminates all the clean up code I >> have to make when starting and stopping when the supervisor is "parallel" >> rather than "under" my client process. >> >> As I said, in general you wouldn't want to do it like that but you *can* >> and it isn't *wrong* and it isn't a *hack*. The Erlang documentation doesn't >> (AFAIK) bring up this scenario but it doesn't make it less useful. >> >> That is all. >> >> >> On 20 May 2011 13:52, Kannan wrote: >> >>> Mazen, >>> >>> You can do the same thing with simple_one_for_one supervisors, >>> one_for_all supervisors and one_for_one supervisors stacked in different >>> levels. >>> >>> >>> >>> >>> >>> On Fri, May 20, 2011 at 2:55 PM, Mazen Harake wrote: >>> >>>> I don't agree with the "never" part. There are corner cases and I would, >>>> in general, absolutely agree with what you wrote but here is one example of >>>> an exception. >>>> >>>> In my IRC library (https://github.com/mazenharake/eirc) I have the >>>> following scenario: >>>> >>>> One can create 1..n clients. Each client is a process (running a >>>> gen_server in eirc_cl.erl). A client can have many processes associated with >>>> it, in my case these are called Bots. Each bot is started and supervised by >>>> a client. A bot shall not terminate unless told to do so (gracefully) or if >>>> the parent dies (i.e the client). Now if I manually start a supervisor >>>> instance inside the gen_server I can simply make use of the supervisor >>>> functionality without handling any of that in my gen_server. I can add and >>>> remove children (bots) dynamically from my supervisor I.e. I don't have to >>>> maintain my own list of them and when I (the client) exits my children (I.e. >>>> the supervisor) will exit and thus my bots will exit... all according to OTP >>>> principals and I don't need to catch exit signals. This makes it REALLY easy >>>> to clean up things since all I have to do is to close the client process, >>>> the client process doesn't even need logic in the terminate callback since >>>> the children will exit with the same reason. If my supervisor was "on the >>>> outside" (like you suggest and which it normally is) I would have to make >>>> sure to clean up after myself with the supervisor. >>>> >>>> So it is much simpler (from an isolation point of view) to (in my case) >>>> start a supervisor Inside the gen_server. >>>> >>>> never say never ;) >>>> >>>> /M >>>> >>>> >>>> >>>> >>>> >>>> On 18 May 2011 14:13, Vance Shipley wrote: >>>> >>>>> On Wed, May 18, 2011 at 11:38:50AM +0200, Roberto Ostinelli wrote: >>>>> } just a quick question: can you think of any case in which starting a >>>>> } supervisor from a gen_server would actually be a perfectly fit idea? >>>>> >>>>> Never. >>>>> >>>>> +---------+ >>>>> | foo_sup | >>>>> +-+-----+-+ >>>>> / \ >>>>> +----------+--+ +--+---------+ >>>>> | bar_sup_sup | | foo_server | >>>>> +---+---------+ +------------+ >>>>> | >>>>> +----+----+ >>>>> | bar_sup | >>>>> +---------+ >>>>> >>>>> Start a supervisor for the new dynamic supervisor(s) and use >>>>> supervisor:start_child/2 from the gen_server to start it. >>>>> >>>>> -- >>>>> -Vance >>>>> _______________________________________________ >>>>> erlang-questions mailing list >>>>> erlang-questions@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>>> >>>> >>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>>> >>> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > > > -- > Best Regards, > - Ahmed Omar > http://nl.linkedin.com/in/adiaa > Follow me on twitter > @spawn_think > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlsson.richard@REDACTED Fri May 20 14:34:45 2011 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Fri, 20 May 2011 14:34:45 +0200 Subject: [erlang-questions] Advanced Erlang Subtleties In-Reply-To: References: <20110520034535.GA6320@mulga.csse.unimelb.edu.au> Message-ID: <4DD65FE5.8020003@gmail.com> On 05/20/2011 01:35 PM, James Churchman wrote: > also does anybody know the answer to my : >> There is a 3rd parameter in the AST for a catch section in a Try/Catch > that is always a match all ( a bit like ERROR_TYPE:ERROR:_ ) does > anybody know what this means? is there an extra option in a catch that > is rarely used? Yes, it's a cheap and compact encoding of the stack trace (as a bignum or binary, I don't remember). This is so that no time is wasted building a symbolic stack trace as a list of tuples that might simply get discarded as soon as the exception is caught, while making it possible to suspend an exception temporarily, drop back into Erlang code to match against a set of catch-patterns, and re-throw the whole thing again if nothing matched. If it's needed for anything, the blob will be unpacked into a symbolic trace. All in all, you're better off pretending you don't know anything about this, apart from the fact that effort has been made to keep exceptions as cheap as possible. /Richard From ivan@REDACTED Fri May 20 14:37:20 2011 From: ivan@REDACTED (Ivan Uemlianin) Date: Fri, 20 May 2011 13:37:20 +0100 Subject: [erlang-questions] Help! rb won't start, and won't stop Message-ID: <4DD66080.2030706@llaisdy.com> Dear All This is my own fault. I recently restarted my remote app, connected to the node in a shell, started rb and called rb:show(), expecting a list of a hundred or so reports since starting the app. I realised too late that rb would show me all the logs in the ten rotating log files. I can't remember what I did next. It included killing the job and quitting the shell. When I came back, rb wouldn't start: 1> {ok,Pid} = rb:start(). ** exception error: no match of right hand side value {error,already_present} But it wouldn't stop either: 2> rb:stop(). ** exception exit: {noproc,{gen_server,call,[rb_server,stop,infinity]}} in function gen_server:call/3 in call from rb:stop/0 It wouldn't show me the reports: > rb:show(1). ** exception exit: {noproc,{gen_server,call, [rb_server,{show_number,1},infinity]}} in function gen_server:call/3 But it wasn't entirely inert: > rb:h(). Report Browser Tool - usage =========================== rb:start() ... Can anybody help me get rb working again? I promise to be more careful next time. With thanks and best wishes Ivan -- ============================================================ Ivan A. Uemlianin Speech Technology Research and Development ivan@REDACTED www.llaisdy.com llaisdy.wordpress.com www.linkedin.com/in/ivanuemlianin "Froh, froh! Wie seine Sonnen, seine Sonnen fliegen" (Schiller, Beethoven) ============================================================ From raimo+erlang-questions@REDACTED Fri May 20 14:38:52 2011 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Fri, 20 May 2011 14:38:52 +0200 Subject: [erlang-questions] Efficiency of a list construction In-Reply-To: <8E910913-40E2-4C0D-B375-985D72E7FDAF@erlang-solutions.com> References: <20110520105035.GK11339@aluminum.local> <8E910913-40E2-4C0D-B375-985D72E7FDAF@erlang-solutions.com> Message-ID: <20110520123852.GA5211@erix.ericsson.se> On Fri, May 20, 2011 at 07:47:15AM -0400, Fr?d?ric Trottier-H?bert wrote: > I would dare say that tail recursion is not exactly important in this example. > > In both cases, you basically end up creating a list, which will hold all the values of all messages. In one case, you will be creating a list of N elements to be carried on the stack, in the other case, you'll be having a stack that is about the size of N elements. > > In the first case, you also have to reverse the list, in the other, you don't. It's not really a big deal IMO to use a call that is not tail recursive when what you are doing is building a list that is in the same order as the items happen. If you look into the stdlib, you'll see that the lists:map/2 function is (or was? haven't looked in a few versions) implemented in a non tail recursive manner. When you think of it, it kind of makes sense too; you give a list of the same size as before, in the right order, for similar speeds, and you'll be avoiding a call to a BIF (reverse/1) on top of it. Messen ist wissen -- von Siemens To measure is to know But it is fun to speculate (to elaborate on the conclusion above). Body recursion: For every message, build it on the heap, push the message handle on the stack (1 word), call yourself meaning push the return address (1 word). If we run out of stack + heap that are in the same memory block (in the current implementation) do a garbage collect that will increase the free space. When the loop is ended we pop one stack frame at the time (1+1 words) and build one list cons cell (2 words). The result is built while we return and requires no garbage collections since the pops from the stack match what's built on the heap. Tail recursion: For every message, build it on the heap, build one list cons cell (2 words) on the heap and loop to yourself. Garbage collect just like above. Practically equivalent to the body recursive variant but build all on the heap and nothing on the stack. When the loop is ended, do the lists:reverse/1 to build the result. A new list is built on the heap requiring the same size as the old list, and the reversed list becomes garbage. So, tail recursion should require a top memory consumption of 2 * size(MsgList) words more than body recursion. This will cause extra garbage collection. Also the lists:reverse/1 is extra work that the body recursive variant avoids. In this case I speculate body recursion wins. In some other implementation where heap and stack are not in the same memory block the situation changes. I know of no such implementation yet. In the Erjang prototype stack space is limited so all body recursion should be avoided. That might be an unacceptable limitation since it impacts so hard at body recursion. > > Now, in the case when you're building a list in a different order or where you basically create more data than necessary by avoiding recursion (ex.: a tail recursive fibonacci vs. a non tail recursive fibonacci), then tail recursion should be chosen, but I see nothing wrong with the flush/0 implementation of Kannan. > > -- > Fred H?bert > http://www.erlang-solutions.com > > > > On 2011-05-20, at 06:50 AM, Vance Shipley wrote: > > > Kannan, > > > > No, it is not tail recursive. This is: > > > > %% @spec() -> [term()] > > %% > > flush() -> > > flush([]). > > > > %% @hidden > > flush(Msgs) -> > > receive > > Msg -> > > flush([Msg | Msgs]); > > after 17 -> > > Msgs > > end. > > > > On Fri, May 20, 2011 at 03:45:19PM +0530, Kannan wrote: > > } Is the following list construction an efficient one? > > } > > } flush() -> > > } receive > > } Msg -> > > } [Msg|flush()] > > } after 17 -> > > } [] > > } end. > > > > -- > > -Vance > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From rtrlists@REDACTED Fri May 20 14:41:11 2011 From: rtrlists@REDACTED (Robert Raschke) Date: Fri, 20 May 2011 13:41:11 +0100 Subject: [erlang-questions] Help! rb won't start, and won't stop In-Reply-To: <4DD66080.2030706@llaisdy.com> References: <4DD66080.2030706@llaisdy.com> Message-ID: On Fri, May 20, 2011 at 1:37 PM, Ivan Uemlianin wrote: > Dear All > > This is my own fault. > > I recently restarted my remote app, connected to the node in a shell, > started rb and called rb:show(), expecting a list of a hundred or so reports > since starting the app. I realised too late that rb would show me all the > logs in the ten rotating log files. > > I can't remember what I did next. It included killing the job and quitting > the shell. > > When I came back, rb wouldn't start: > > 1> {ok,Pid} = rb:start(). > ** exception error: no match of right hand side value > {error,already_present} > At this point your shelll crashed, taking the already started rb with it. > > But it wouldn't stop either: > > 2> rb:stop(). > ** exception exit: {noproc,{gen_server,call,[rb_server,stop,infinity]}} > in function gen_server:call/3 > in call from rb:stop/0 > Thus attempting to stop it gives you this error. > > It wouldn't show me the reports: > > > rb:show(1). > ** exception exit: {noproc,{gen_server,call, > > [rb_server,{show_number,1},infinity]}} > in function gen_server:call/3 > > You should be able to simply rb:start() it again now. Robby -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf.wiger@REDACTED Fri May 20 14:56:07 2011 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Fri, 20 May 2011 14:56:07 +0200 Subject: [erlang-questions] Efficiency of a list construction In-Reply-To: <20110520123852.GA5211@erix.ericsson.se> References: <20110520105035.GK11339@aluminum.local> <8E910913-40E2-4C0D-B375-985D72E7FDAF@erlang-solutions.com> <20110520123852.GA5211@erix.ericsson.se> Message-ID: On 20 May 2011, at 14:38, Raimo Niskanen wrote: > In the Erjang prototype stack space > is limited so all body recursion should be avoided. In all fairness to Erjang, it actually handles most cases of body recursion quite well. The times I've seen it blow up, it was always in pretty-printing a binary (a deeply-body-recursive function). BR, Ulf Ulf Wiger, CTO, Erlang Solutions, Ltd. http://erlang-solutions.com From ivan@REDACTED Fri May 20 14:57:24 2011 From: ivan@REDACTED (Ivan Uemlianin) Date: Fri, 20 May 2011 13:57:24 +0100 Subject: [erlang-questions] Help! rb won't start, and won't stop In-Reply-To: References: <4DD66080.2030706@llaisdy.com> Message-ID: <4DD66534.50105@llaisdy.com> Dear Robert Thanks for your comments. You're right, the shell crashes, but I can't start rb from either the restarted shell or a fresh shell: 1> self(). <0.15437.1> 2> rb:start(). {error,already_present} 3> self(). <0.15437.1> 4> rb:stop(). ** exception exit: {noproc,{gen_server,call,[rb_server,stop,infinity]}} in function gen_server:call/3 in call from rb:stop/0 5> self(). <0.15444.1> 6> rb:start(). {error,already_present} 7> rb doesn't seem to show up on appmon or pman either. Could it somehow have detached itself? Is there some other way I can find its Pid and kill it? Best wishes Ivan On 20/05/2011 13:41, Robert Raschke wrote: > > On Fri, May 20, 2011 at 1:37 PM, Ivan Uemlianin > wrote: > > Dear All > > This is my own fault. > > I recently restarted my remote app, connected to the node in a > shell, started rb and called rb:show(), expecting a list of a > hundred or so reports since starting the app. I realised too late > that rb would show me all the logs in the ten rotating log files. > > I can't remember what I did next. It included killing the job and > quitting the shell. > > When I came back, rb wouldn't start: > > 1> {ok,Pid} = rb:start(). > ** exception error: no match of right hand side value > {error,already_present} > > > At this point your shelll crashed, taking the already started rb with it. > > > But it wouldn't stop either: > > 2> rb:stop(). > ** exception exit: > {noproc,{gen_server,call,[rb_server,stop,infinity]}} > in function gen_server:call/3 > in call from rb:stop/0 > > > Thus attempting to stop it gives you this error. > > > It wouldn't show me the reports: > > > rb:show(1). > ** exception exit: {noproc,{gen_server,call, > > [rb_server,{show_number,1},infinity]}} > in function gen_server:call/3 > > > You should be able to simply rb:start() it again now. > > Robby > -- ============================================================ Ivan A. Uemlianin Speech Technology Research and Development ivan@REDACTED www.llaisdy.com llaisdy.wordpress.com www.linkedin.com/in/ivanuemlianin "Froh, froh! Wie seine Sonnen, seine Sonnen fliegen" (Schiller, Beethoven) ============================================================ From vasdeveloper@REDACTED Fri May 20 15:04:33 2011 From: vasdeveloper@REDACTED (Kannan) Date: Fri, 20 May 2011 18:34:33 +0530 Subject: [erlang-questions] supervisor started from gen_server In-Reply-To: References: <20110518121242.GG7320@aluminum.local> Message-ID: You will have assume and concentrate on many other things other than concentrating on your application logic. On Fri, May 20, 2011 at 5:53 PM, Mazen Harake wrote: > Correct. > > A Bot (in this case) is seen as an extension of the client. Thus if the bot > (which by implication is the client) is misbehaving or enters a faulty state > the client crashes. The result of this is that the client is restarted (and > the corresponding bots are reset). > > /M > > > On 20 May 2011 14:19, Ahmed Omar wrote: > >> Hi Mazen , >> >> One question rises here about this. What happens when the processes under >> that supervisor reach the maximum number of restarts, and the supervisor is >> terminated. In a "traditional" supervision tree, the higher level supervisor >> shall react to that. In your case, it will be the gen_server which i imagine >> will crash then? >> >> On Fri, May 20, 2011 at 2:00 PM, Mazen Harake wrote: >> >>> Of course you *can* but the point I'm trying to make is that it's not >>> "wrong" to do it like I did and it doesn't break OTP behaviour and is >>> actually convenient. Doing it like I did eliminates all the clean up code I >>> have to make when starting and stopping when the supervisor is "parallel" >>> rather than "under" my client process. >>> >>> As I said, in general you wouldn't want to do it like that but you *can* >>> and it isn't *wrong* and it isn't a *hack*. The Erlang documentation doesn't >>> (AFAIK) bring up this scenario but it doesn't make it less useful. >>> >>> That is all. >>> >>> >>> On 20 May 2011 13:52, Kannan wrote: >>> >>>> Mazen, >>>> >>>> You can do the same thing with simple_one_for_one supervisors, >>>> one_for_all supervisors and one_for_one supervisors stacked in different >>>> levels. >>>> >>>> >>>> >>>> >>>> >>>> On Fri, May 20, 2011 at 2:55 PM, Mazen Harake wrote: >>>> >>>>> I don't agree with the "never" part. There are corner cases and I >>>>> would, in general, absolutely agree with what you wrote but here is one >>>>> example of an exception. >>>>> >>>>> In my IRC library (https://github.com/mazenharake/eirc) I have the >>>>> following scenario: >>>>> >>>>> One can create 1..n clients. Each client is a process (running a >>>>> gen_server in eirc_cl.erl). A client can have many processes associated with >>>>> it, in my case these are called Bots. Each bot is started and supervised by >>>>> a client. A bot shall not terminate unless told to do so (gracefully) or if >>>>> the parent dies (i.e the client). Now if I manually start a supervisor >>>>> instance inside the gen_server I can simply make use of the supervisor >>>>> functionality without handling any of that in my gen_server. I can add and >>>>> remove children (bots) dynamically from my supervisor I.e. I don't have to >>>>> maintain my own list of them and when I (the client) exits my children (I.e. >>>>> the supervisor) will exit and thus my bots will exit... all according to OTP >>>>> principals and I don't need to catch exit signals. This makes it REALLY easy >>>>> to clean up things since all I have to do is to close the client process, >>>>> the client process doesn't even need logic in the terminate callback since >>>>> the children will exit with the same reason. If my supervisor was "on the >>>>> outside" (like you suggest and which it normally is) I would have to make >>>>> sure to clean up after myself with the supervisor. >>>>> >>>>> So it is much simpler (from an isolation point of view) to (in my case) >>>>> start a supervisor Inside the gen_server. >>>>> >>>>> never say never ;) >>>>> >>>>> /M >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 18 May 2011 14:13, Vance Shipley wrote: >>>>> >>>>>> On Wed, May 18, 2011 at 11:38:50AM +0200, Roberto Ostinelli wrote: >>>>>> } just a quick question: can you think of any case in which starting >>>>>> a >>>>>> } supervisor from a gen_server would actually be a perfectly fit >>>>>> idea? >>>>>> >>>>>> Never. >>>>>> >>>>>> +---------+ >>>>>> | foo_sup | >>>>>> +-+-----+-+ >>>>>> / \ >>>>>> +----------+--+ +--+---------+ >>>>>> | bar_sup_sup | | foo_server | >>>>>> +---+---------+ +------------+ >>>>>> | >>>>>> +----+----+ >>>>>> | bar_sup | >>>>>> +---------+ >>>>>> >>>>>> Start a supervisor for the new dynamic supervisor(s) and use >>>>>> supervisor:start_child/2 from the gen_server to start it. >>>>>> >>>>>> -- >>>>>> -Vance >>>>>> _______________________________________________ >>>>>> erlang-questions mailing list >>>>>> erlang-questions@REDACTED >>>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> erlang-questions mailing list >>>>> erlang-questions@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >> >> >> -- >> Best Regards, >> - Ahmed Omar >> http://nl.linkedin.com/in/adiaa >> Follow me on twitter >> @spawn_think >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rtrlists@REDACTED Fri May 20 15:08:49 2011 From: rtrlists@REDACTED (Robert Raschke) Date: Fri, 20 May 2011 14:08:49 +0100 Subject: [erlang-questions] Help! rb won't start, and won't stop In-Reply-To: <4DD66534.50105@llaisdy.com> References: <4DD66080.2030706@llaisdy.com> <4DD66534.50105@llaisdy.com> Message-ID: On Fri, May 20, 2011 at 1:57 PM, Ivan Uemlianin wrote: > Dear Robert > > Thanks for your comments. > > You're right, the shell crashes, but I can't start rb from either the > restarted shell or a fresh shell: > > 1> self(). > <0.15437.1> > 2> rb:start(). > {error,already_present} > 3> self(). > <0.15437.1> > > 4> rb:stop(). > ** exception exit: {noproc,{gen_server,call,[rb_server,stop,infinity]}} > in function gen_server:call/3 > in call from rb:stop/0 > 5> self(). > <0.15444.1> > 6> rb:start(). > {error,already_present} > 7> > > rb doesn't seem to show up on appmon or pman either. > > Could it somehow have detached itself? Is there some other way I can find > its Pid and kill it? > > Ah, rb:start() doesn't actually link. Try supervisor:terminate_child(sasl_sup, rb_server), supervisor:delete_child(sasl_sup, rb_server). That should remove the references for you. And then I would suggest using rb:start_link() instead of the normal start. Robby -------------- next part -------------- An HTML attachment was scrubbed... URL: From mazen.harake@REDACTED Fri May 20 15:16:56 2011 From: mazen.harake@REDACTED (Mazen Harake) Date: Fri, 20 May 2011 15:16:56 +0200 Subject: [erlang-questions] supervisor started from gen_server In-Reply-To: References: <20110518121242.GG7320@aluminum.local> Message-ID: Actually, it is exactly the opposite. I can concentrate more on my application and less on what I need to clean up after it (or even when it comes to maintaining it... I still have to go through my client to achieve the bot handling). The only difference, really, is that all the supervisors I'm creating could be under a seperate "supervisor for bot_supervisors" but then I wouldn't have the same isolation. But my main point still is this: Don't say "Never", because sometimes it is extremely useful. On 20 May 2011 15:04, Kannan wrote: > You will have assume and concentrate on many other things other than > concentrating on your application logic. > > > On Fri, May 20, 2011 at 5:53 PM, Mazen Harake wrote: > >> Correct. >> >> A Bot (in this case) is seen as an extension of the client. Thus if the >> bot (which by implication is the client) is misbehaving or enters a faulty >> state the client crashes. The result of this is that the client is restarted >> (and the corresponding bots are reset). >> >> /M >> >> >> On 20 May 2011 14:19, Ahmed Omar wrote: >> >>> Hi Mazen , >>> >>> One question rises here about this. What happens when the processes under >>> that supervisor reach the maximum number of restarts, and the supervisor is >>> terminated. In a "traditional" supervision tree, the higher level supervisor >>> shall react to that. In your case, it will be the gen_server which i imagine >>> will crash then? >>> >>> On Fri, May 20, 2011 at 2:00 PM, Mazen Harake wrote: >>> >>>> Of course you *can* but the point I'm trying to make is that it's not >>>> "wrong" to do it like I did and it doesn't break OTP behaviour and is >>>> actually convenient. Doing it like I did eliminates all the clean up code I >>>> have to make when starting and stopping when the supervisor is "parallel" >>>> rather than "under" my client process. >>>> >>>> As I said, in general you wouldn't want to do it like that but you *can* >>>> and it isn't *wrong* and it isn't a *hack*. The Erlang documentation doesn't >>>> (AFAIK) bring up this scenario but it doesn't make it less useful. >>>> >>>> That is all. >>>> >>>> >>>> On 20 May 2011 13:52, Kannan wrote: >>>> >>>>> Mazen, >>>>> >>>>> You can do the same thing with simple_one_for_one supervisors, >>>>> one_for_all supervisors and one_for_one supervisors stacked in different >>>>> levels. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, May 20, 2011 at 2:55 PM, Mazen Harake wrote: >>>>> >>>>>> I don't agree with the "never" part. There are corner cases and I >>>>>> would, in general, absolutely agree with what you wrote but here is one >>>>>> example of an exception. >>>>>> >>>>>> In my IRC library (https://github.com/mazenharake/eirc) I have the >>>>>> following scenario: >>>>>> >>>>>> One can create 1..n clients. Each client is a process (running a >>>>>> gen_server in eirc_cl.erl). A client can have many processes associated with >>>>>> it, in my case these are called Bots. Each bot is started and supervised by >>>>>> a client. A bot shall not terminate unless told to do so (gracefully) or if >>>>>> the parent dies (i.e the client). Now if I manually start a supervisor >>>>>> instance inside the gen_server I can simply make use of the supervisor >>>>>> functionality without handling any of that in my gen_server. I can add and >>>>>> remove children (bots) dynamically from my supervisor I.e. I don't have to >>>>>> maintain my own list of them and when I (the client) exits my children (I.e. >>>>>> the supervisor) will exit and thus my bots will exit... all according to OTP >>>>>> principals and I don't need to catch exit signals. This makes it REALLY easy >>>>>> to clean up things since all I have to do is to close the client process, >>>>>> the client process doesn't even need logic in the terminate callback since >>>>>> the children will exit with the same reason. If my supervisor was "on the >>>>>> outside" (like you suggest and which it normally is) I would have to make >>>>>> sure to clean up after myself with the supervisor. >>>>>> >>>>>> So it is much simpler (from an isolation point of view) to (in my >>>>>> case) start a supervisor Inside the gen_server. >>>>>> >>>>>> never say never ;) >>>>>> >>>>>> /M >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 18 May 2011 14:13, Vance Shipley wrote: >>>>>> >>>>>>> On Wed, May 18, 2011 at 11:38:50AM +0200, Roberto Ostinelli wrote: >>>>>>> } just a quick question: can you think of any case in which starting >>>>>>> a >>>>>>> } supervisor from a gen_server would actually be a perfectly fit >>>>>>> idea? >>>>>>> >>>>>>> Never. >>>>>>> >>>>>>> +---------+ >>>>>>> | foo_sup | >>>>>>> +-+-----+-+ >>>>>>> / \ >>>>>>> +----------+--+ +--+---------+ >>>>>>> | bar_sup_sup | | foo_server | >>>>>>> +---+---------+ +------------+ >>>>>>> | >>>>>>> +----+----+ >>>>>>> | bar_sup | >>>>>>> +---------+ >>>>>>> >>>>>>> Start a supervisor for the new dynamic supervisor(s) and use >>>>>>> supervisor:start_child/2 from the gen_server to start it. >>>>>>> >>>>>>> -- >>>>>>> -Vance >>>>>>> _______________________________________________ >>>>>>> erlang-questions mailing list >>>>>>> erlang-questions@REDACTED >>>>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> erlang-questions mailing list >>>>>> erlang-questions@REDACTED >>>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>>>> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>>> >>> >>> >>> -- >>> Best Regards, >>> - Ahmed Omar >>> http://nl.linkedin.com/in/adiaa >>> Follow me on twitter >>> @spawn_think >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan@REDACTED Fri May 20 15:20:35 2011 From: ivan@REDACTED (Ivan Uemlianin) Date: Fri, 20 May 2011 14:20:35 +0100 Subject: [erlang-questions] solved: Re: Help! rb won't start, and won't stop In-Reply-To: References: <4DD66080.2030706@llaisdy.com> <4DD66534.50105@llaisdy.com> Message-ID: <4DD66AA3.9080703@llaisdy.com> Dear Robby > Ah, rb:start() doesn't actually link. Try > > supervisor:terminate_child(sasl_sup, rb_server), > supervisor:delete_child(sasl_sup, rb_server). Thanks! rb up and running again! > And then I would suggest using rb:start_link() instead of the normal start. rb doesn't seem to have start_link/0 > rb:start_link(). ** exception error: undefined function rb:start_link/0 I'm happy with start/0 now that it's working. Thanks again! Ivan On 20/05/2011 14:08, Robert Raschke wrote: > > On Fri, May 20, 2011 at 1:57 PM, Ivan Uemlianin > wrote: > > Dear Robert > > Thanks for your comments. > > You're right, the shell crashes, but I can't start rb from either > the restarted shell or a fresh shell: > > 1> self(). > <0.15437.1> > 2> rb:start(). > {error,already_present} > 3> self(). > <0.15437.1> > > 4> rb:stop(). > ** exception exit: > {noproc,{gen_server,call,[rb_server,stop,infinity]}} > in function gen_server:call/3 > in call from rb:stop/0 > 5> self(). > <0.15444.1> > 6> rb:start(). > {error,already_present} > 7> > > rb doesn't seem to show up on appmon or pman either. > > Could it somehow have detached itself? Is there some other way I > can find its Pid and kill it? > > > Ah, rb:start() doesn't actually link. Try > > supervisor:terminate_child(sasl_sup, rb_server), > supervisor:delete_child(sasl_sup, rb_server). > > That should remove the references for you. > > And then I would suggest using rb:start_link() instead of the normal start. > > Robby > -- ============================================================ Ivan A. Uemlianin Speech Technology Research and Development ivan@REDACTED www.llaisdy.com llaisdy.wordpress.com www.linkedin.com/in/ivanuemlianin "Froh, froh! Wie seine Sonnen, seine Sonnen fliegen" (Schiller, Beethoven) ============================================================ From michael.eugene.turner@REDACTED Fri May 20 15:57:32 2011 From: michael.eugene.turner@REDACTED (Michael Turner) Date: Fri, 20 May 2011 22:57:32 +0900 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: <3E70F4ECA6ED459C936583EE3B7301EC@srstrong.com> References: <661C1ED1-0683-435C-8BF0-5EAB2289D546@erlang-solutions.com> <3E70F4ECA6ED459C936583EE3B7301EC@srstrong.com> Message-ID: "... looking at both backward *and* forward compatibility issues (what sort of things might this change prevent us from doing in the future?)" I have repeatedly asked people here what this change would break, and in particular how it might compromise backward compatibility. Nobody has answered, so far. Since the change amounts to the compiler silently inserting a function name during parsing at points where some IDE environments already already insert the name literally when you type ";", it's pretty hard to see how there could be a backward compatibility issue. As for forward compatibility, we have it from Joe that syntax changes hardly every happen anyway. So if change is very unlikely to happen, forward compatiblity isn't much of an issue either, is it? As for how many meetings it would take Ericsson to establish that the risk is low/zero, well, OK, got me: I've worked as a software engineer in a couple of large companies, so I know that these things can take time. In fact, I remember life at one networking company where any single engineering change order to the production system required no fewer than 25 signatures. So you may have a point there. (Although I thought part of the point of open source was to circumvent that kind of bureaucratic tarpit. Guess I was wrong.) "Emacs for one would need work since it's syntax highlighting would now be broken." It would only be broken for any code that took advantage of the change I suggest. Which would start out at exactly zero percent of the Erlang code out there. As the supposed "harm" grew, well, somebody would go and modify whatever needed to be modified, to make syntax highlighting work as it does in Emacs already for the analogous syntax in Clojure. "If this is so important to you ...." It is not that important to me (at the moment.) However, like anybody else, I hate having my case for change twisted by others, and I hate objections to ideas (mine and others) when the objections don't actually hold water. If you think the thread is a waste of *your* time, you're free to not contribute to it. -michael turner On Fri, May 20, 2011 at 4:12 PM, Steve Strong wrote: > Do you seriously think that a compiler team of a well-established and > widely used language would implement a new syntax in less than a day? The > code change itself may be relatively trivial (or a total pain in the arse, > I've not looked at the current compiler code and could believe either), but > whichever it is, it will be dwarfed by the design meetings held prior to > making the change - looking at both backward *and* forward compatibility > issues (what sort of things might this change prevent us from doing in the > future?), plus the testing that would need to be performed after. > > And then there's all the tools that would be broken. Emacs for one would > need work since it's syntax highlighting would now be broken. All this for > a really minor change that, judging from the responses on this list, not > that many people even want. > > Dude, this thread has gone on long enough and wasted way too much time. If > this is so important to you, then do it yourself (after all, it's less than > a days work) and publish the changes. > > Cheers, > > Steve > > -- > Steve Strong, Director, id3as > twitter.com/srstrong > > On Friday, 20 May 2011 at 07:29, Michael Turner wrote: > > Thank you, Fr?d?ric, for taking a serious look at the idea. However, I see > a few of the same unsubstantiated objections raised, with a couple more > questionable ones added. > > "- It makes it less obvious that a function has many clauses (see Steve > Davis' code)" > > WITH Steve's style of indentation. I suggested a more readable alternative, > where the "(Args)->" part has indentation column to themselves. (Curiously, > you employ my suggested indentation style yourself, below, in a supposedly > "ambiguous" code sample.) > > "- it somewhat unifies the syntax with funs, but then funs still finish > with 'end' and take no name." > > Perhaps syntax would become even more regular than you suggest. What I > propose results in a grammar more like this: > > function: > clause-list + "." > fun: > "fun" + clause-list + "end" > clause: > [optional name] (arg-list) guards -> stmt-list > > This is, if anything, more regular than the grammar is now. Yes, it > *syntactically* allows for a *different* "optional name", but so does the > current grammar; finding head mismatches *already* requires a separate step. > And I question whether it requires the parser to produce a different AST > than we get now, for parse-transform purposes. > > The above syntax also permits naming in funs. Is that so bad? As ROK has > suggested, pehaps funs ought to be allowed (limited-scope) names to > facilitate recursive definition. I happen to think it would work just as > well to re-use the keyword "fun" to refer to the fun in the process of being > defined. But there's something to be said for self-documenting recursive > funs, so I could go either way on that one. Or both ways. (I hear the moans: > "Not *another* way to do the same thing..." -- as if they were actually the > same. And as if I weren't proposing here to do things ONE way.) > > "- it creates more learning overhead if both forms are used." > > That depends on how you learn (and teach) a language. Really: how much more > page space does it require to show a slightly different way to do something? > And then there are different learner styles. After learning the basics of a > language, I tend to flip to an appendix like "syntax summary" (in BNF and > other semi-formal styles), to start exploring the meaning of different > combinatorial possibilities -- it's often one of the most clarifying and > delightful exercises I undertake. Alas, neither of the Erlang books has any > such an appendix (mandatory for a programming language primer, I would have > thought.) For me, that has made learning Erlang harder. > > "- it's not faster (compile time, might even make compiling slower)" > > You've got to be kidding. It's long been known: the time complexity of > parsing is overwhelmingly dominated by scanning. Code written in the form I > propose would have fewer tokens to scan. > > "- it doesn't make the parser code easier to maintain" > > It might, actually. See above. > > "- it's making a lot of documentation obsolete that will need to be > updated. This is common to all changes though." > > Yes, it is. Not to mention that the documentation on Erlang syntax is due > for an upgrade anyway. The first hit I get on "Erlang" and "fun" yields the > section "Syntax of funs", here: > > http://www.erlang.org/doc/programming_examples/funs.html#id59209 > > Yes, believe it: no coverage of the multi-clause case. > > "You'll be creating a hell of a lot more work ...." > > Ah, it seems almost obligatory on this thread: exaggeration asserted as > fact. Would it really require even as much as a day's work on the parser? > Yes, it would require updating documentation of Erlang syntax, but that > documentation that (see above) clearly needs a little work anyway. > > "Oh and lastly, you could also have to consider this ambiguity ...." > > It wouldn't even be an ambiguity. It would only be a weird and pointless > way to write that code. And that's IF someone wrote code like that. Well, > anybody can write crappy and confusing code that abuses any language > feature. (There it is: my own obligatory exaggeration for this thread.) Any > "obfuscated Erlang contest" would likely to whack the worst Obfuscated C out > the ballpark. (And that's no exaggeration.) > > -michael turner > > 2011/5/19 Fr?d?ric Trottier-H?bert > > Well let's take a look here. Syntax doesn't have to break old code to > change, that's a good point. > > You'll see that if you try {lists, sort}([3,2,1]), you will obtain [1,2,3]. > This basic fun syntax dates from before Erlang actually had funs (fun > M:F/A). You'll notice that it was less complex, tends to avoid verbosity and > is somewhat more readable than doing (fun lists:sort/1)([1,2,3]). Going to > the new syntax didn't break any code, didn't require old working code to be > rewritten (things still work the old way, and parametrized modules are based > on that bit of syntax) and people just ignore it if they don't need it. Yet > people did the switch from {Mod, Fun} to fun M:F/A. > > Why? Because, I figure, people generally liked the new way better: it's > faster (apparently much faster), much cleaner in intent and purposes, and > way easier to figure out that we're actually dealing with a higher order > function and not some weird concept. Plus you have to consider that in many > places, you can just use 'Var(Args)' with either form. This switch had many > wins over conciseness. > > If we try to do the same with your suggestion for the new Erlang syntax, we > can basically see that it has a few advantages: > > - reduces typing required by avoiding name repetitions > - it doesn't break existing code > - it somewhat unifies the syntax with funs, but then funs still finish with > 'end' and take no name. > > > I, however, see the following disadvantages: > > - it creates multiple standards left to personal preference > - it makes it less obvious that a function has many clauses (see Steve > Davis' code) > - it creates more learning overhead if both forms are used. {Mod,Fun} for > funs has no overhead because it's basically deprecated and nobody uses it. > - All the existing tools have to be updated to understand it -- at least > those working on source files (and this includes editors and whatnot) > > To this, you must add a multiplier damage (heh) for things it doesn't make > better: > - it's not faster (compile time, might even make compiling slower) > - it doesn't make the parser code easier to maintain > - it doesn't make maintaining code in modules easier (except for some > readability benefits) > - it's not helping people understand the language better (based on my > observations that people have no problems with the current form when it > comes to understanding) > - it's making a lot of documentation obsolete that will need to be updated. > This is common to all changes though. > > In my opinion, typing less code, even if it doesn't break compatibility, is > not worth the change. You'll be creating a hell of a lot more work if only > to get a bit more concise and consistent syntax on a thing where people > don't even agree you get better readability. > > > Oh and lastly, you could also have to consider this ambiguity -- is the > following bit of code acceptable? > > my_function > (a,b,c) -> {a,b,c}; > (a,c,b) -> {a,b,v}; > my_function > (c,b,a) -> {a,b,c}. > > > On 2011-05-19, at 09:43 AM, Michael Turner wrote: > > > "Erlang is sufficiently mature that the syntax is now very difficult to > change." > > > > Nobody has yet told me why this proposed change would break any existing > code, or why it would require any significant work on the parser. > > > -- > Fred H?bert > http://www.erlang-solutions.com > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.eugene.turner@REDACTED Fri May 20 16:11:58 2011 From: michael.eugene.turner@REDACTED (Michael Turner) Date: Fri, 20 May 2011 23:11:58 +0900 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: <749E5278-61D7-4A58-82D0-A128D0972C97@cs.otago.ac.nz> References: <749E5278-61D7-4A58-82D0-A128D0972C97@cs.otago.ac.nz> Message-ID: "It seems to me that Michael Turner's argument is an argument from conservatism. Algol, Basic, COBOL, Fortran, PL/I, Simula, XPL, Java, Javascript, PHP, Perl, all of these languages write a function name once and only once at the beginning of a function." But which of those allow more than one argument list? It isn't just that people are used to the function name being written only once. (That isn't true for C++ member functions, and there are *lots* of C++ programmers out there.) I think the indentation style I suggest also makes it more immediately obvious that Erlang features a kind of pattern-directed invocation. As for what you claim is more readable, remember: the intuitive is the familiar. Someone who is entirely new to Erlang will perceive things differently. The only way to make the proposition "syntax X is more readable" a scientific one is to test -- on people *new* to Erlang. After all, someday, all of us will have passed from the scene and it will be only the new people who matter. -michael turner On Fri, May 20, 2011 at 5:07 PM, Richard O'Keefe wrote: > > On 19/05/2011, at 3:46 AM, Michael Turner wrote: > > > "You're being pedantic dude." > > > > If I argued only from syntactic consistency, you'd have a point. Frankly, > I don't really care about syntactic consistency, if it doesn't get me > something. Having to type less gets me something. Having more readable code > gets me something. Those are practical considerations, not mere pedantic > ones. Dude. > > > > What you have as > > > > some_func(X, Y) -> > > %% Long bit of code > > ...; > > some_func(X, []) -> > > %% More code > > > > could, as I proposed above, also be written > > > > some_func > > (X,Y) -> %% long bit of code > > ...; > > (X,[]) -> %% More code > > .... > > > > Why is this less readable to you? > > For the same reasons it is less readable to me. > Readable code PROVIDES HELPS FOR THE READER. > > > You could answer, "Because it's not what I'm used to seeing in Erlang > programs," but that begs the question. If people were more used to seeing > the latter -- because making Erlang syntactically more self-consistent made > it possible -- that argument wouldn't have much force -- except as an > argument from pure conservatism. > > It seems to me that Michael Turner's argument is an argument from > conservatism. > Algol, Basic, COBOL, Fortran, PL/I, Simula, XPL, Java, Javascript, PHP, > Perl, > all of these languages write a function name once and only once at the > beginning > of a function. So therefore Erlang should do the same? Give me a break: > those > languages that "the majority of programmers" are familiar with don't *have* > multiple clause functions. > > Let's take an example *adapted* from "Pattern Matching in Scheme". > > (define parse > (match-lambda > [(and s (? symbol?) (not ?lambda)) > (make-Var s)] > [(? number? n) > (make-Const n)] > [(?lambda args body) > (make-Lam args (parse body))] > [(f args ...) > (make-App (parse f) (map parse args))] > [x (error ?syntax "invalid expression")])) > > Now let's write that in Erlang: > > parse(S) when isatom(S), S \== lambda -> > make_var(S); > parse(N) when isnumber(N) -> > make_const(N); > parse([lambda,Args,Body]) -> > make_lam(Args, parse(Body)); > parse([F|Args]) -> > make_app(parse(F), [parse(Arg) || Arg <- Args]); > parse(_) -> > error(syntax, <<"invalid expression">>). > > That paper ends with a page full of code defining a single > function, and looking at it, I can see what pattern is being > matched, but not why, and can't really tell without the aid > of a ruler. > > I've played with things like that, and I never want to do > so again. I greeted SML, then Haskell, and Erlang, with load > cries of joy. > > > And this is entirely apart from "long bit of code" being a classic Smell > anyway: > > > > http://www.soberit.hut.fi/mmantyla/BadCodeSmellsTaxonomy.htm > > > > -michael turner > > You will find that some of the things in that taxonomy are, um, > expressed in an over-general way in the interests of brevity. > For example, I don't see any reason to ban switch statements > from Java. They don't do anything that dynamic dispatch can > do, and dynamic dispatch doesn't do what switches can do. > > "Long Methods" is very much a matter of taste; how long is too > long? I've just recommended to someone that they add about > another 100 lines of code to a certain method today; 90 of > those lines are a table of strings. There is nothing evil > about a table of strings. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.eugene.turner@REDACTED Fri May 20 16:13:19 2011 From: michael.eugene.turner@REDACTED (Michael Turner) Date: Fri, 20 May 2011 23:13:19 +0900 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: <1799C0B6-EA5B-469E-94EE-18F3F3A16C52@cs.otago.ac.nz> References: <1930B4D4-54DD-4F80-ACDE-BBE983315E64@hates.ms> <1799C0B6-EA5B-469E-94EE-18F3F3A16C52@cs.otago.ac.nz> Message-ID: "And why do you think I don't use Clojure?" Uh, Richard, where did he say he thought that? -michael turner On Fri, May 20, 2011 at 5:40 PM, Richard O'Keefe wrote: > > On 19/05/2011, at 5:03 AM, Jack Moffitt wrote: > > >> I'm still waiting for the answer to the real showstopper question: would > any > >> existing code break, under my proposal? > > > > Assuming the answer is no, then I think it's fine to fix the > > inconsistency an add this alternate notation. > > No, it's not fine. > > It fixes the WRONG END of the inconsistency. > It's like saying "Ooh, these people have two legs and those > people have one leg, the easiest thing to do is to cut one > leg off those who have too." > > It harms readability in the eyes of a lot of people. > > Like I said, you would have to pay me big money to read > code written in that style. > > It certainly breaks *my* pretty-printer and editor. > > Michael Turner is at perfect liberty to add any feature he > likes to his copy of Erlang. He is at liberty to offer it > to other people. > > > I'll also point out that this is name-less clause syntax is the same > > as in Clojure: > > > > (defn > > mymax > > ([x] x) > > ([x y] (if (> x y) x y)) > > ([x y & more] > > (reduce mymax (mymax x y) more))) > > And why do you think I don't use Clojure? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.eugene.turner@REDACTED Fri May 20 16:30:17 2011 From: michael.eugene.turner@REDACTED (Michael Turner) Date: Fri, 20 May 2011 23:30:17 +0900 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: <73FD1684-4D13-40E1-8CE6-7CFE266AB382@cs.otago.ac.nz> References: <661C1ED1-0683-435C-8BF0-5EAB2289D546@erlang-solutions.com> <73FD1684-4D13-40E1-8CE6-7CFE266AB382@cs.otago.ac.nz> Message-ID: "... because THAT IS COVERED IN THE REFERENCE MANUAL WHERE THE VERY FIRST THING AFTER THE SECTION HEADING SHOWS A MULTICLAUSE FUN." And (he says, ears ringing slightly) that somehow makes it OK for any other part of the documentation to be wrong, even when your average learner is far more likely to encounter the erroneous passage first? I eventually ran across the reference manual description. Thanks for the update about the proportions of time spent scanning vs. parsing. I'm under the influence of something I heard Bill Joy (then a student of Sue Graham's) say about lex and yacc back around 1980 or so. In any case, can we at least agree that the change I suggest is going to have minimal impact on parsing times? "If both the existing readable alternative and the proposed horrible one are supported, the code *has* to increase in volume, and *has* to become less maintainable." Even if it actually reduces the number of grammar rules, or keeps the number the same, and even if it means the same amount of head-match checking we have now? "You are attacking one of the features of Erlang that I have found most helpful." I found this "feature" helpful in a way myself: from doing some Prolog programming, I had some experience with writing code in this pattern. But when I was doing Prolog programming, I had the same complaint about Prolog: dreary repetition of redundant identifiers where whitespace and indentation would (I thought) enhance readability. It took some getting used to. But I suppose I could have learned to love it if I'd done more Prolog programming. We have an eye of the beholder problem, here, obviously. -michael turner 2011/5/20 Richard O'Keefe > > On 20/05/2011, at 5:29 PM, Michael Turner wrote: > > "- it's not faster (compile time, might even make compiling slower)" > > > > You've got to be kidding. It's long been known: the time complexity of > parsing is overwhelmingly dominated by scanning. Code written in the form I > propose would have fewer tokens to scan. > > That used to be true. However, it's not clear that it _is_ true when the > parser is > written in Yecc, as the Erlang parser is. And it's not terribly important > anyway, > because in the compilers I know anything about, the cost of scanning AND > parsing > put together is less than half the total time. (For example, one body of > code that > I work with is parsed and semantic checked in under a second, but takes > about 90 > seconds for code generation.) > > I just wrote a parser for someone else's scripting language last week. > Scanning > took less time than parsing, and the only reason code generation doesn't > dominate > both is that it doesn't do any. > > > > "- it doesn't make the parser code easier to maintain" > > > > It might, actually. See above. > > If both the existing readable alternative and the proposed horrible one are > supported, the code *has* to increase in volume, and *has* to become less > maintainable. > > > > > "- it's making a lot of documentation obsolete that will need to be > updated. This is common to all changes though." > > > > Yes, it is. Not to mention that the documentation on Erlang syntax is due > for an upgrade anyway. The first hit I get on "Erlang" and "fun" yields the > section "Syntax of funs", here: > > > > http://www.erlang.org/doc/programming_examples/funs.html#id59209 > > > > Yes, believe it: no coverage of the multi-clause case. > > Yes, because THAT IS COVERED IN THE REFERENCE MANUAL WHERE THE VERY > FIRST THING AFTER THE SECTION HEADING SHOWS A MULTICLAUSE FUN. > > 1. You want to learn about syntax? > Check the reference manual. > 2. You want to learn about something that goes > in expressions? > Check the expressions chapter. > 3. You want to learn about a particular kind of > form? Check the table of contents for that chapter. > 4. See 'fun expressions'? > Click on it. > > And there you are. > > If you deliberately don't look in the reference manual, it's not > the fault of Erlang or its documenters. > > There are plenty of things to improve, but before complaining about > the syntax, people really do have an obligation to look in the most > obvious place. > > "Oh and lastly, you could also have to consider this ambiguity ...." > > > > It wouldn't even be an ambiguity. It would only be a weird and pointless > way to write that code. > > And omitting the function name _anywhere_ in the first place is a weird and > pointless way to write code. > > You are attacking one of the features of Erlang that I have found most > helpful. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ttmrichter@REDACTED Fri May 20 16:40:14 2011 From: ttmrichter@REDACTED (Michael Richter) Date: Fri, 20 May 2011 22:40:14 +0800 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: <1930B4D4-54DD-4F80-ACDE-BBE983315E64@hates.ms> <20110519093746.GB27904@erix.ericsson.se> Message-ID: On 19 May 2011 18:47, Michael Turner wrote: > "It would, as others have pointed out, also be much harder to jump into a > module and _know_ what the clause does since the function's name can be > pages away." > > It would only be harder ("much"??) if you *chose*, in such cases, to use > the syntax I propose to bring over from multi-clause funs. In the case you > bring up, it might be wiser not to. And what I propose clearly allows > everyone to continue with the present syntax. So your argument for > readability in this case comes down to "somebody might not use this language > feature wisely." (*facepalm*). > Jumping into the party a bit late, but this caught my eye. You do realize that sometimes people have to look at the code written by others, right? Whether I choose to use this new syntax or not (and for the record I hate it), it will inevitably still impact me if others choose to use it. -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.eugene.turner@REDACTED Fri May 20 16:51:12 2011 From: michael.eugene.turner@REDACTED (Michael Turner) Date: Fri, 20 May 2011 23:51:12 +0900 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: Message-ID: > > > Because (a) the generalisation I suggested was > fun > {; }... > end > where is either a VARIABLE or omitted, > and is identical in each clause. > But '' is NOT a variable, now is it? > > Thank you for the clarification. I see now that you had the fun "name" in upper case, in the code sample on the other thread. Perhaps that's enough for most people on this list to infer -- automatically and immediately -- that you really meant "variable" even when you were saying "name". But I've mostly been using regular programming languages for the last 30 years, which offer a little more freedom in variable naming, and I still fail sometimes to automatically think "variable" just because a non-macro identifier starts in upper case -- which is another old Prolog convention I always had trouble with. I apologize for being, um, you know ... merely average? It's certainly a solution to a problem, I'd like to see it (or something like it) succeed, and I wish you luck with it. -michael turner On Fri, May 20, 2011 at 4:42 PM, Richard O'Keefe wrote: > > On 19/05/2011, at 2:18 AM, Michael Turner wrote: > > > Another objection raised against this syntax change is that all > functional languages violate DRY in this manner, so it's OK if Erlang does > it too. This is a Principle of Least Surprise argument, and not bad as far > as it goes. But how far does it go? > > > > Erlang will have a better chance of greater success and survival if you > consider your recruitment base to be the overwhelming majority of > programmers. > > I had a lengthy response to this which SquirrelMail (apparently that's the > name of the > WebMail system here) managed to destroy. Sigh. > > Erlang has already survived very well for 30+ years with pretty much its > present syntax. > It has also succeeded very well. > > > And from what I can tell, > > > > http://www.langpop.com > > > > the overwhelming majority of programmers have no experience to speak of, > > Erlang's strengths come from being DIFFERENT. > > There's a thing much discussed, much derided, and much practiced in > Australia > and New Zealand, called "cultural cringe". Look it up. Cultural cringe > hurt > ISO Prolog. (Prolog _had_ a notation for integers in bases 2..36, but the > ISO committee threw it away and copied C instead, for base 16 only. They > also changed the precedence of at least one operator to match C better than > Prolog.) > If we go by fashion, we'll change Erlang to look like PHP or COBOL. > (Estimates of COBOL code volume range from 1e11 to 5e11 lines.) > > Oh, I'd like all sorts of changes to Erlang syntax. After Haskell, I find > it > quite verbose. I once designed a "Haskerl" syntax for Erlang that reduced > the > line count by a factor of 1.6. But syntax is not the most important thing > about > Erlang (or LFE would not be of interest), and it's not really what needs > the > most attention. I think the Dialyzer is easily the most dramatic and > important > thing that's happened to Erlang in some time, and if we want to talk about > improvements, that might have the highest payoff. > > > when it comes to functional programming languages. Appealing to the > "cross-training" benefit of coming from other FP languages seems like a > pretty weak argument. Especially since all I'm asking for here is syntactic > consistency *within* Erlang -- a PLoS argument in itself. > > > > Richard O'Keefe suggests that the syntactic consistency goal is better > met by allowing a kind of limited-scope special-case fun name, permitting, > e.g. > > > > Fact = fun F(0) -> 1; F(N) -> N*F(N-1) end. > > > > I could get behind that too, but I don't follow his reasoning from > syntactic consistency, which is apparently that an unnamed fun has a name, > it's just the degenerate case of a name. It's really there. We just can't > see it. Hm, really? If that were true in Erlang as it stands, shouldn't I be > able to write it this way? > > > > Fact = fun (0) -> 1; (N) -> N*''(N-1) end. > > Because (a) the generalisation I suggested was > fun > {; }... > end > where is either a VARIABLE or omitted, > and is identical in each clause. > But '' is NOT a variable, now is it? > > And (b) the generalisation I suggested was to use > the SAME in each clause, and a completely > missing name is NOT the same as an empty but present > atom. (This is like the way that in SQL92 a NULL > string is very different from an empty string.) > > And note that I did not say that this is what Erlang *DOES* > do but what it might some day be *EXTENDED* to do as a way > of letting people write recursive funs. > > By the way, some earlier posting from somebody said that > Erlang was alone in allowing multiple clauses in funs. > Not so. > > Erlang Haskell ML > yes yes no Are multiple arguments allowed in a lambda? > yes no yes Are multiple clauses allowed in a lambda? > > Erlang: > fun ([_|_]) -> true > ; ([]) -> false > end > > Standard ML: > fn (_:_) -> true > | [] -> false > > While you *can* write > > val default = fn (SOME x) _ -> x > | NONE d -> d > > in SML, it is normal practice to write > > fun default (SOME x) _ = x > | default NONE d = d > > and I think most SML programmers would regard the first alternative > as perversely unreadable. > > > > > > > What Richard's suggesting appears to require a rigorous re-think of how > scopes are defined in Erlang. > > Not in the least. The scope of a function name variable would be the > function itself, > just like any other variable in the arguments of the clauses. > > 1> X = 1. > 1 > 2> F = fun (X) -> ok ; (_) -> uh_oh end. > #Fun > 3> F(2). > ok > > See how the X in the fun was *not* the X outside? > Same rule exactly for fun-names. > > > W > > > hat I'm suggesting amounts to simply asking the compiler to do some of > your tedious keying for you. > > > > -michael turner > > (A) If repeating the function name is the most tedious keying you have, > how fortunate you are! > (B) People with a decent text-editor don't have a problem anyway. > One reason for putting case, if, fun, and receive semicolons at > the beginning of the line is so that when you end a line with a > semicolon, the editor can automatically > - go back to the first preceding line to have a letter or ' > in column 1; > - copy the function name into a work space > - go back where it started > - insert the work space. > I did this years ago for Prolog. I found it distracting, so > switched the feature off, but anyone who really really hated > retyping function names should be able to program this in a > few minutes. > (C) The names are not there for the benefit of the compiler, but > for the benefit of PEOPLE. When you are reading someone else's > code, it HELPS to see the function name in each clause. > And that's why I'm willing to give head-room to fun-names. > I really loathe seeing a bare argument list without any indication > of what it's the argument list *of*. > > > > > > On Wed, May 18, 2011 at 6:16 PM, Michael Turner < > michael.eugene.turner@REDACTED> wrote: > > I can say > > > > fun (1)->2; > > (2)->1 > > end > > > > but, oddly, I can't define a named function in the analogous way, e.g.: > > > > factorial > > (1) -> 1; > > (N) -> N*factorial(N-1). > > > > gives me a syntax error. I find the latter more readable than > > > > factorial(1) -> 1; > > factorial(2) -> N*fact(N-1). > > I do not. In fact I find the first version of factorial rather horrible. > If you really want to do that, you can write > > factorial(N) -> case N of > (1) -> 1; > (N) -> N*factorial(N-1) end. > > right now. Just don't ask me to read it for anything less than NZD > 400/hour. > > > > It's also less to type and to read, which is consistent with the DRY > principle ("Don't Repeat Yourself"). > > The DRY principle was not handed down on Mt Sinai. > It is a rule of thumb, no more and no less. > And indeed, it violates something I have found to be an excellent > guide, that a *controlled* use of redundancy is an aid to correctness. > > For example, :- spec is redundant, but > - it lets Erlang detect a difference between what you DID write and > what you MEANT to write > - someone can read the :- spec without having to read the code. > > There are other examples of good redundancy in Erlang. > > The keyword here, of course, is *controlled* redundancy; just enough to > do something useful (like helping human beings read your code, or > permitting some check), not too much. > > > It also looks a *little* bit more like the mathematical convention for > defining these sorts of functions, where you have "f(x) = ", centered > vertically to the left of a big left "{" that (left-)encloses the list of > expression/parameter-condition pairs in a two-column format, e.g., > > That is one mathematical convention, followed in Miranda, and leading to > guards in Haskell and Erlang. It is regrettable that SML does not have > them, but at least there's the 'nowhere' preprocessor to provide them. > > There are other mathematical conventions. > "The Fibonacci numbers are defined using the linear recurrence relation > > > with seed values: > > > > > " (Wikipedia entry on recurrence relations). > > This is the style that Haskell, Clean, Mercury, SML, CAML, and so on > follow. > > > It seems to me that, if anything, this requires only a *simplification* > of the Erlang parser. That leaves only one obvious objection: would any > existing code break if Erlang syntax were altered to allow this? > > Probably not. However, the parser is a tiny part of the Erlang system, > even a > tiny part of the compiler. Simplicity of the parser per se is hardly worth > worrying about. What matters is having a readable language. > > Even if the change were made, every Erlang book and paper ever printed > shows > the existing style. How would newbies react to code that looked like > nothing > they had ever been taught about? What would happen to Erlang > language-sensitive > editing tools, would they cope with the new syntax? I know that the crude > pretty-printer I wrote for Erlang would have trouble, and the commands I > now > find useful for moving to the next/previous clause would cease to work. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew@REDACTED Fri May 20 16:53:37 2011 From: andrew@REDACTED (Andrew Thompson) Date: Fri, 20 May 2011 10:53:37 -0400 Subject: [erlang-questions] erlmail problems In-Reply-To: <4DD65A85.5000605@gmail.com> References: <4DD65A85.5000605@gmail.com> Message-ID: <20110520145337.GH11203@hijacked.us> On Fri, May 20, 2011 at 03:11:49PM +0300, Martin Dimitrov wrote: > Hi, > > I am trying to use erlmail as an IMAP client only. I modified the > library to use ssl instead of gen_tcp sockets but I receive errors when > the library is parsing the return line from googlemail: > > * OK Gimap ready for requests from 79.126.56.221 i9if507573yhn.157\r\n > > This line seems to me ok. > Had anyone used erlmail as an IMAP client? Any advise? Other libraries? > I tried to play with erlmail some and I couldn't get anywhere. I was trying the IMAP server component though, not the client. After digging into it a little I basically wrote the whole codebase off as a loss because I had trouble figuring out how the code was *supposed* to work, let alone figuring out why it wasn't working. I don't know of an alternate IMAP client library for erlang, though. I've been writing an IMAP server implementation for the last couple weeks (https://github.com/Vagabond/diemap) but that's probably not much help (its also really unfinished). I was considering eventually writing a client to go with it, as I did with my SMTP library but if I do it'll be a while. Andrew From jameschurchman@REDACTED Fri May 20 16:54:59 2011 From: jameschurchman@REDACTED (James Churchman) Date: Fri, 20 May 2011 15:54:59 +0100 Subject: [erlang-questions] Advanced Erlang Subtleties In-Reply-To: <4DD65FE5.8020003@gmail.com> References: <20110520034535.GA6320@mulga.csse.unimelb.edu.au> <4DD65FE5.8020003@gmail.com> Message-ID: <8A358ED0-87B3-41F2-A6FF-3EC070F93BE1@gmail.com> Very interesting and makes a lot of sense.... i was hoping that 'better off pretending you don't know anything about this' was the case and there was not some huge set of optional extra stuff onto of a try catch! On 20 May 2011, at 13:34, Richard Carlsson wrote: > On 05/20/2011 01:35 PM, James Churchman wrote: >> also does anybody know the answer to my : >>> There is a 3rd parameter in the AST for a catch section in a Try/Catch >> that is always a match all ( a bit like ERROR_TYPE:ERROR:_ ) does >> anybody know what this means? is there an extra option in a catch that >> is rarely used? > > Yes, it's a cheap and compact encoding of the stack trace (as a bignum or binary, I don't remember). This is so that no time is wasted building a symbolic stack trace as a list of tuples that might simply get discarded as soon as the exception is caught, while making it possible to suspend an exception temporarily, drop back into Erlang code to match against a set of catch-patterns, and re-throw the whole thing again if nothing matched. If it's needed for anything, the blob will be unpacked into a symbolic trace. > > All in all, you're better off pretending you don't know anything about this, apart from the fact that effort has been made to keep exceptions as cheap as possible. > > /Richard From ebegumisa@REDACTED Fri May 20 17:04:36 2011 From: ebegumisa@REDACTED (Edmond Begumisa) Date: Sat, 21 May 2011 01:04:36 +1000 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: <5F87F807-9E87-48A5-A238-C9C5904C5C39@cs.otago.ac.nz> References: <5F87F807-9E87-48A5-A238-C9C5904C5C39@cs.otago.ac.nz> Message-ID: > consider the needs of READERS in preference to WRITERS. I found this statement nicely summed up the conflicting views on this thread. Very well put. And it puts the issue to rest IMO. - Edmond - On Fri, 20 May 2011 18:27:03 +1000, Richard O'Keefe wrote: > > On 19/05/2011, at 4:08 AM, Michael Turner wrote: > >> "Sorry, but Erlang doesn't *need* a better chance of survival." >> >> Now, wait, I'm really pretty sure that, less than a year ago, I saw >> both Peyton-Jones and Armstong in a video, speculating about the future >> of their respective favorite languages, and openly wondering what the >> long-term future held. > > And? Haskell is booming. They tried to avoid success and failed > miserably. > >> In the meantime, I haven't noticed a dramatic increase in the frequency >> of Erlang job postings, though perhaps it's gone up. However, a >> doubling would still leave the number small. > > That does not mean that Erlang is under threat. Come to think of it, R > is booming > also. There are at least 81 mirrors of CRAN to handle the download > volumes. How > many R jobs do you see? >> >> "Changing core language features that are solid,..." >> >> Except that that what I proposes fixes a weak spot (among other >> things): failed syntactic consistency. > > No, it leaves the *weak* spot (the absence of names in funs) along > and smashes the *strong* spot. >> >> "... well thought out ..." >> >> Except that Joe Armstrong has just admitted (on this thread, IIRC) that >> the reason for the inconsistency is that they just didn't think about >> it at the time...." > > If you mean when "funs" were introduced, that may be so. > But the repeated function names were copied from languages where it *WAS* > well thought out, rather like you probably would not fault someone for > designing a programming language using [] for array subscripting. > >> >> "... and non-harmful ..." >> >> Implying that what I suggest here IS harmful? > > Yes, it is > It would seriously impair readability. > It would break several code processing tools that I use. > It would drastically impair the usefulness of every existing Erlang book. >> >> Actually not. No amount of education and experience will make repeating >> the function name with every clause a DRY issue, for those who find >> that repetition as more of an obstacle than otherwise. > > Remember always to consider the needs of READERS in preference to > WRITERS. > > Take Haskell, as an example. One of the advantages of Haskell is that > the > types of functions can be inferred from their bodies (as long as you > stick > to the standard language and don't use the rank 2 extension GHC offers). > Why then do most Haskell programmers recommend writing down function > types > anyway, even though that violates DRY? > > Because although the type *is* implicit in the code, and the *compiler* > can figure it out, that doesn't mean it's easy for *humans*. > > If you are one of the people who find repeating function names an > obstacle > (on present evidence, a set of cardinality one), > - you don't have to use Erlang > - you can always write cases if you want > - you could look into LFE > - you could write your own preprocessor > > >> No amount of education and experience will keep people from wondering, >> "Why this strange inconsistency?" > > As a matter of fact, I've known about Erlang since about a year (maybe > two) since the first paper > on it. Since well before it *had* funs, in fact. And you know, I've > *never* had that thought. > I don't experience any inconsistency. > >> oAnd better documentation and training will only make more people ask >> that question. I didn't ask that question until I *stumbled* on the >> extended syntax for funs; I didn't know about it before. > > "Extended syntax for funs?" What's that? The syntax of funs is > described in > chapter 7 of the reference manual, the chapter on expressions, which is > exactly > where you would expect to find it. > > The inconsistency I see is that functions are OK but funs > (a) do not permit a visible function name > -- just like Haskell, Clean, SML, CAML, &c > (b) begin with "fun" instead of just beginning > -- just like Haskell, Clean, SML, &c > (c) end with "end" instead of ending with a "." > -- the other languages I mentioned do not have any > -- terminator, so I usually find myself having to > -- wrap them in parentheses. It's quite nice not > -- having to do that. > > However, (b) and (c) are unsurprising because funs are > *expressions* and normal function definitions are not. > > If you are that upset about (a), I suggest that the inconsistency > should be resolved by allowing funs to have names, as I've suggested, > because that would fix the *other* difference between funs and > normal functions, which is that normal functions can be directly > recursive, and funs cannot. > > Your proposal to add a definition style that I find horrible for > normal functions fails to do anything about that *other* difference > between functions and funs. > > I repeat, you are urging that a *strong* spot be smashed to make > it consistent with a *weak* spot, which is quite the wrong way around. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From michael.eugene.turner@REDACTED Fri May 20 17:19:43 2011 From: michael.eugene.turner@REDACTED (Michael Turner) Date: Sat, 21 May 2011 00:19:43 +0900 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: <5F87F807-9E87-48A5-A238-C9C5904C5C39@cs.otago.ac.nz> Message-ID: Anyone who thinks that I address the needs of writers in preference to readers on this thread hasn't been reading me with much attention. Readability is somewhat in the eye of the beholder. A lot of the beholders on this list are seasoned Erlang programmers. It's pretty clear what they prefer: the way things are. I happen to find the indented style I propose more readable. I have also said that I think programmers new to Erlang would tend to agree, although without a scientific test it would be hard to establish this, I admit. Some day, if Erlang survives, all the eyes on it will be new, because we'll all pass from the scene, eventually, one way or another. So it's not as if newbie opinion is utterly irrelevant here. Disagreeing with my expressed position on readability is fair. Writing as if I'd never expressed that position, however, is not. -michael turner On Sat, May 21, 2011 at 12:04 AM, Edmond Begumisa < ebegumisa@REDACTED> wrote: > consider the needs of READERS in preference to WRITERS. >> > > I found this statement nicely summed up the conflicting views on this > thread. Very well put. And it puts the issue to rest IMO. > > - Edmond - > > > > On Fri, 20 May 2011 18:27:03 +1000, Richard O'Keefe > wrote: > > >> On 19/05/2011, at 4:08 AM, Michael Turner wrote: >> >> "Sorry, but Erlang doesn't *need* a better chance of survival." >>> >>> Now, wait, I'm really pretty sure that, less than a year ago, I saw both >>> Peyton-Jones and Armstong in a video, speculating about the future of their >>> respective favorite languages, and openly wondering what the long-term >>> future held. >>> >> >> And? Haskell is booming. They tried to avoid success and failed >> miserably. >> >> In the meantime, I haven't noticed a dramatic increase in the frequency >>> of Erlang job postings, though perhaps it's gone up. However, a doubling >>> would still leave the number small. >>> >> >> That does not mean that Erlang is under threat. Come to think of it, R is >> booming >> also. There are at least 81 mirrors of CRAN to handle the download >> volumes. How >> many R jobs do you see? >> >>> >>> "Changing core language features that are solid,..." >>> >>> Except that that what I proposes fixes a weak spot (among other things): >>> failed syntactic consistency. >>> >> >> No, it leaves the *weak* spot (the absence of names in funs) along >> and smashes the *strong* spot. >> >>> >>> "... well thought out ..." >>> >>> Except that Joe Armstrong has just admitted (on this thread, IIRC) that >>> the reason for the inconsistency is that they just didn't think about it at >>> the time...." >>> >> >> If you mean when "funs" were introduced, that may be so. >> But the repeated function names were copied from languages where it *WAS* >> well thought out, rather like you probably would not fault someone for >> designing a programming language using [] for array subscripting. >> >> >>> "... and non-harmful ..." >>> >>> Implying that what I suggest here IS harmful? >>> >> >> Yes, it is >> It would seriously impair readability. >> It would break several code processing tools that I use. >> It would drastically impair the usefulness of every existing Erlang book. >> >>> >>> Actually not. No amount of education and experience will make repeating >>> the function name with every clause a DRY issue, for those who find that >>> repetition as more of an obstacle than otherwise. >>> >> >> Remember always to consider the needs of READERS in preference to WRITERS. >> >> Take Haskell, as an example. One of the advantages of Haskell is that the >> types of functions can be inferred from their bodies (as long as you stick >> to the standard language and don't use the rank 2 extension GHC offers). >> Why then do most Haskell programmers recommend writing down function types >> anyway, even though that violates DRY? >> >> Because although the type *is* implicit in the code, and the *compiler* >> can figure it out, that doesn't mean it's easy for *humans*. >> >> If you are one of the people who find repeating function names an obstacle >> (on present evidence, a set of cardinality one), >> - you don't have to use Erlang >> - you can always write cases if you want >> - you could look into LFE >> - you could write your own preprocessor >> >> >> No amount of education and experience will keep people from wondering, >>> "Why this strange inconsistency?" >>> >> >> As a matter of fact, I've known about Erlang since about a year (maybe >> two) since the first paper >> on it. Since well before it *had* funs, in fact. And you know, I've >> *never* had that thought. >> I don't experience any inconsistency. >> >> oAnd better documentation and training will only make more people ask >>> that question. I didn't ask that question until I *stumbled* on the extended >>> syntax for funs; I didn't know about it before. >>> >> >> "Extended syntax for funs?" What's that? The syntax of funs is described >> in >> chapter 7 of the reference manual, the chapter on expressions, which is >> exactly >> where you would expect to find it. >> >> The inconsistency I see is that functions are OK but funs >> (a) do not permit a visible function name >> -- just like Haskell, Clean, SML, CAML, &c >> (b) begin with "fun" instead of just beginning >> -- just like Haskell, Clean, SML, &c >> (c) end with "end" instead of ending with a "." >> -- the other languages I mentioned do not have any >> -- terminator, so I usually find myself having to >> -- wrap them in parentheses. It's quite nice not >> -- having to do that. >> >> However, (b) and (c) are unsurprising because funs are >> *expressions* and normal function definitions are not. >> >> If you are that upset about (a), I suggest that the inconsistency >> should be resolved by allowing funs to have names, as I've suggested, >> because that would fix the *other* difference between funs and >> normal functions, which is that normal functions can be directly >> recursive, and funs cannot. >> >> Your proposal to add a definition style that I find horrible for >> normal functions fails to do anything about that *other* difference >> between functions and funs. >> >> I repeat, you are urging that a *strong* spot be smashed to make >> it consistent with a *weak* spot, which is quite the wrong way around. >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Fri May 20 17:36:17 2011 From: erlang@REDACTED (Joe Armstrong) Date: Fri, 20 May 2011 17:36:17 +0200 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: Message-ID: On Fri, May 20, 2011 at 12:44 AM, James Churchman wrote: > winner for the most nit-pickey thread ever > > also : > > >Me, I'd like to say > > > > L = [{foo, fun(X,Y) -> ... end}, {bar, fun(X) -> ... end}] > > > then have couple of new bifs Mod = list_to_mod(L) to compose a module > from a load of funs and mod_to_list to do the inverse. > > should be possible by generating a bit of ast and would indeed be a cool > addition to the runtime :-) > Unfortunately not. /Joe > > > > On 19 May 2011 23:05, Edmond Begumisa wrote: > >> As I child I asked my mathematician father: >> >> "Why is the number pad of a telephone in the flipped order from the number >> pad on a calculator/computer keyboard?" >> >> His answer: "That's just the way it is." >> >> Sometimes "that's just the way it is" is a perfectly sufficient and >> reasonable answer to both questions: why something is done a particular way; >> and why it shouldn't be changed. >> >> Mind you on the noob argument: when I first started learning Erlang (my >> first functional language -- I had tried Lisp and gave up), I found the >> current syntax a very good learning aid. To use Turner's original example... >> >> factorial(0) -> 1; >> factorial(N) when N > 0 -> N*factorial(N-1). >> >> I would read this as... >> >> "The factorial of 0 is 1; the factorial of N when N is greater than zero >> is N times the factorial of N - 1." >> >> Having the function name at the beginning of each clause helped me greatly >> to adapt to the declarative nature of Erlang. In contrast, I first struggled >> with multi-clause funs because my brain wanted so badly to use the anatomy >> of a function that I was so used to from imperative languages. >> >> So I'd argue that changing this might make code actually *harder* for >> noobs when they come across it. The function names reinforce the declarative >> nature of Erlang, me thinks. >> >> Besides, every programmer I know is a touch-typist -- it's not _that_ much >> work typing the function names :) >> >> - Edmond - >> >> >> >> > factorial >>>>>> > (1) -> 1; >>>>>> > (N) -> N*factorial(N-1). >>>>>> > >>>>>> > gives me a syntax error. I find the latter more readable than >>>>>> > >>>>>> > factorial(1) -> 1; >>>>>> > factorial(2) -> N*fact(N-1). >>>>>> >>>>> >>> >> >> >> >> >> On Fri, 20 May 2011 03:19:11 +1000, Mike Oxford >> wrote: >> >> Noting that I'm not against core language changes where critically >>> warranted, why is this one particular thing such an issue to you? >>> >>> Erlang is not an ivory-tower-on-a-hill-university-project. It's an >>> organically-grown beast that gets down in the trenches and brawls in the >>> mud. >>> If you don't like it, write it off as an "Erlang wart." Every language >>> has >>> them. If you don't like it then write your own, or your own parser. >>> >>> For what it's worth, some users (such as myself) actually PREFER it the >>> way >>> it is because it makes code-scanning easier from a visual standpoint. >>> Yes, I'm one of those people who will put "comment breaks" between >>> methods >>> in my code, too, regardless of language. >>> >>> And to reference your copy-paste-mutate argument....what do you think >>> we'll >>> be doing for every internal case-clause? Yes, that's right, >>> copy-paste-mutate the pattern matches except that you now have your >>> logical >>> branches at indent-level-1 with, potentially, the rest of your code that >>> doesn't deal with argument-specific code instead of at indent-level-0. >>> If >>> you need "common chunks of code" well, I'm pretty sure that's why we have >>> methods. To wit, write your "unified interface" and case it yourself >>> and >>> call the argument specific sub-method. >>> >>> My vote: keep it as it is. >>> >>> >>> >>> -mox >>> >>> >>> On Wed, May 18, 2011 at 9:39 PM, Michael Turner < >>> michael.eugene.turner@REDACTED> wrote: >>> >>> Joe, with all due respect, I think you've misinterpreted DRY. It's not a >>>> matter of writing something again because you can't find where it's >>>> already >>>> implemented. In fact, the canonical example of DRY is to write something >>>> that works for one case, and then, rather than define it as a function, >>>> template or macro, and invoke it with varying parameters, instead >>>> copy-paste-mutate for each case. In fact, the most common violations of >>>> DRY >>>> are *precisely* when you know where the repeated code is, either because >>>> you've just found it or because you've just written it. >>>> >>>> "DRY says that every piece of system knowledge should have one >>>> authoritative, unambiguous representation." >>>> >>>> http://www.artima.com/intv/dry.html >>>> >>>> Erlang function definition syntax has two representations in the parser >>>> -- >>>> for no good reason I can see. Why? >>>> >>>> "Changing syntax is *incredibly difficult* project managers get >>>> apoplectic >>>> at the thought of retesting million lines of code -" >>>> >>>> No existing code will use the syntax I suggest. So how can any of it >>>> break? >>>> >>>> I have yet to get an answer: what could this proposed change possibly >>>> break, even *theoretically*? >>>> >>>> -michael turner >>>> >>>> On Thu, May 19, 2011 at 6:47 AM, Joe Armstrong >>>> wrote: >>>> >>>> >>>>> >>>>> On Wed, May 18, 2011 at 5:29 PM, Parnell Springmeyer < >>>>> ixmatus@REDACTED>wrote: >>>>> >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>> Hash: SHA1 >>>>>> >>>>>> Sorry, but Erlang doesn't *need* a better chance of survival. This >>>>>> language is not just growing, it's booming. Changing core language >>>>>> features that are solid, well thought out, and non-harmful (in other >>>>>> words, they are, FEATURES) to make it more "adoptable" is a lot like >>>>>> someone saying, "you have to quit that quirky smile so other people >>>>>> will >>>>>> like you more." >>>>>> >>>>>> >>>>> Languages survive forever once they get to the point where >>>>> >>>>> 1) legacy applications in the language still earn money >>>>> 2) it costs more to convert to a new language than maintain the >>>>> existing app in the old language >>>>> >>>>> Erlang reached this point, many years ago. >>>>> >>>>> Right now Erlang companies have a commercial advantage >>>>> over non-erlang companies and so there is not much point in >>>>> trying to spread the language further - you just loose your commercial >>>>> advantage. >>>>> >>>>> /Joe >>>>> >>>>> >>>>> >>>>>> Sometimes, yes, there are features in a language that could use >>>>>> refinement - but many times, in a mature language, the ratio between >>>>>> need and usefulness in refining a feature further, drops >>>>>> significantly. >>>>>> >>>>>> Instead of changing something that is solid, educate the people that >>>>>> have a hard time grasping it, build killer example applications that >>>>>> exhibit the quirky style and idioms to a T - people /will/ follow it, >>>>>> almost to a religious end. >>>>>> >>>>>> That's actually what I like about Erlang the most, the documentation >>>>>> has >>>>>> so many gems in it like the efficiency guide (where many common idioms >>>>>> are expressed with clear DO and DON'T DO examples) and style guide. >>>>>> >>>>>> RE: syntactic consistency: Erlang's syntax *IS* consistent - it's more >>>>>> consistent than many languages I've touched. >>>>>> >>>>>> Is Erlang easy for a Perl programmer? I bet not, and Perl's syntax is >>>>>> less consistent than Erlang's is in my opinion. The issue you are >>>>>> attempting to get at is (again) an educational and experience one, not >>>>>> something that is inherently wrong with the language or its expression >>>>>> itself. >>>>>> >>>>>> I'm actually baffled by the efforts people are putting into different >>>>>> Erlang VM frontends that look like Ruby or Python. Good on them for >>>>>> exercising the freedom of open source but /why/? Erlang's syntax is >>>>>> almost beautiful to me now after using it, it's so well suited for >>>>>> what >>>>>> Erlang is good at! >>>>>> >>>>>> Erlang isn't that great for general purpose programming - you use >>>>>> Python, Ruby, C, D, etc... for stuff like that. Erlang is great at >>>>>> fault >>>>>> tolerance, easy parallelism (which isn't easy!), and hot code >>>>>> loading. Features that are so difficult to do in the traditional >>>>>> imperative environment that (to date) I have not seen a single >>>>>> implementation of any one of those features that even approaches the >>>>>> completeness of Erlang's. >>>>>> >>>>>> Michael Turner writes: >>>>>> >>>>>> > Another objection raised against this syntax change is that all >>>>>> > functional languages violate DRY in this manner, so it's OK if >>>>>> Erlang >>>>>> > does it too. This is a Principle of Least Surprise argument, and not >>>>>> > bad as far as it goes. But how far does it go? >>>>>> > >>>>>> > Erlang will have a better chance of greater success and survival if >>>>>> you >>>>>> > consider your recruitment base to be the overwhelming majority of >>>>>> > programmers. And from what I can tell, >>>>>> > >>>>>> > http://www.langpop.com >>>>>> > >>>>>> > the overwhelming majority of programmers have no experience to speak >>>>>> > of, when it comes to functional programming languages. Appealing to >>>>>> the >>>>>> > "cross-training" benefit of coming from other FP languages seems >>>>>> like a >>>>>> > pretty weak argument. Especially since all I'm asking for here is >>>>>> > syntactic consistency *within* Erlang -- a PLoS argument in itself. >>>>>> > >>>>>> > Richard O'Keefe suggests that the syntactic consistency goal is >>>>>> better >>>>>> > met by allowing a kind of limited-scope special-case fun name, >>>>>> > permitting, e.g. >>>>>> > >>>>>> > Fact = fun F(0) -> 1; F(N) -> N*F(N-1) end. >>>>>> > >>>>>> > I could get behind that too, but I don't follow his reasoning from >>>>>> > syntactic consistency, which is apparently that an unnamed fun has a >>>>>> > name, it's just the degenerate case of a name. It's really there. >>>>>> We >>>>>> > just can't see it. Hm, really? If that were true in Erlang as it >>>>>> > stands, shouldn't I be able to write it this way? >>>>>> > >>>>>> > Fact = fun (0) -> 1; (N) -> N*''(N-1) end. >>>>>> > >>>>>> > Looks like it's not quite that simple. It compiles, but it doesn't >>>>>> know >>>>>> > what module to look in for '', when it comes time to execute. In the >>>>>> > shell, I get an error indicating that it tried to resolve ''/1 as a >>>>>> > shell command. Even if I put it in a .erl file and compile it, >>>>>> there's >>>>>> > no obvious way to tell the compiler what module to look in. >>>>>> ?MODULE:'' >>>>>> > doesn't work. Nor does '':'', which I tried just for the hell of it. >>>>>> > >>>>>> > What Richard's suggesting appears to require a rigorous re-think of >>>>>> how >>>>>> > scopes are defined in Erlang. What I'm suggesting amounts to simply >>>>>> > asking the compiler to do some of your tedious keying for you. >>>>>> > >>>>>> > -michael turner >>>>>> > >>>>>> > >>>>>> > On Wed, May 18, 2011 at 6:16 PM, Michael Turner < >>>>>> > michael.eugene.turner@REDACTED> wrote: >>>>>> > >>>>>> > I can say >>>>>> > >>>>>> > fun (1)->2; >>>>>> > (2)->1 >>>>>> > end >>>>>> > >>>>>> > but, oddly, I can't define a named function in the analogous >>>>>> way, >>>>>> > e.g.: >>>>>> > >>>>>> > factorial >>>>>> > (1) -> 1; >>>>>> > (N) -> N*factorial(N-1). >>>>>> > >>>>>> > gives me a syntax error. I find the latter more readable than >>>>>> > >>>>>> > factorial(1) -> 1; >>>>>> > factorial(2) -> N*fact(N-1). >>>>>> > >>>>>> > It's also less to type and to read, which is consistent with the >>>>>> > DRY principle ("Don't Repeat Yourself"). And it lends itself to >>>>>> > reading a function definition as a set of cases. I think for >>>>>> Erlang >>>>>> > newbies, it should therefore would be preferred: it helps >>>>>> > underscore the pattern-matching style of Erlang function >>>>>> > invocation. >>>>>> > >>>>>> > It also looks a *little* bit more like the mathematical >>>>>> convention >>>>>> > for defining these sorts of functions, where you have "f(x) = ", >>>>>> > centered vertically to the left of a big left "{" that (left-) >>>>>> > encloses the list of expression/parameter-condition pairs in a >>>>>> > two-column format, e.g., >>>>>> > >>>>>> > http://cnx.org/content/m29517/latest/Picture%2047.png >>>>>> > >>>>>> > So there's a (weak) argument from the Principle of Least >>>>>> Surprise >>>>>> > here as well. >>>>>> > >>>>>> > It seems to me that, if anything, this requires only a >>>>>> > *simplification* of the Erlang parser. That leaves only one >>>>>> obvious >>>>>> > objection: would any existing code break if Erlang syntax were >>>>>> > altered to allow this? >>>>>> > >>>>>> > -michael turner >>>>>> > >>>>>> > _______________________________________________ >>>>>> > erlang-questions mailing list >>>>>> > erlang-questions@REDACTED >>>>>> > http://erlang.org/mailman/listinfo/erlang-questions >>>>>> >>>>>> - -- >>>>>> Parnell "ixmatus" Springmeyer (http://ixmat.us) >>>>>> -----BEGIN PGP SIGNATURE----- >>>>>> Version: GnuPG/MacGPG2 v2.0.17 (Darwin) >>>>>> Comment: GPGTools - http://gpgtools.org >>>>>> >>>>>> iQEcBAEBAgAGBQJN0+XsAAoJEPvtlbpI1POLEXEIAJrjAGVTkveBi5/akYNMjBEX >>>>>> 8wI9twatnXh8sfg2ohGKr3P1hj4jTr9ARrG5wiB9OCArRkBymnjFeY5g2dkBDOhN >>>>>> aN722l+yDPpUewAM58m0dDoDHjrHXvxF1MJejQJGhQ+Nr9fM+7G+4QIrCN9RvX1S >>>>>> QTAS+OqOnl8lsS98yvUiXXLB5ehdHcR46Ix6Sq7UwSvqaOKZMoPrzkTtW3VyS5kf >>>>>> i/uGbPZ1I3KQJYRShk2QlLis/tpXGtLDnYc1E5uADqeClDXy5Au6LWpNqUjNIiWw >>>>>> h8I2emcBq5Ur7nivNUYgnVMjg+0qTkQOtttPpOJ25xIYv07L+eMfXneb5nRx4hc= >>>>>> =GGPU >>>>>> -----END PGP SIGNATURE----- >>>>>> _______________________________________________ >>>>>> erlang-questions mailing list >>>>>> erlang-questions@REDACTED >>>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>>>> >>>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>>> >>>> >> >> -- >> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebegumisa@REDACTED Fri May 20 17:36:06 2011 From: ebegumisa@REDACTED (Edmond Begumisa) Date: Sat, 21 May 2011 01:36:06 +1000 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: <5F87F807-9E87-48A5-A238-C9C5904C5C39@cs.otago.ac.nz> Message-ID: As I described previously: I actually think that the current syntax is *better for newbies* (especially those coming from imperative languages) since it drills-in Erlang's declarative nature. I view your proposal as something to cater for the experienced Erlanger who wants an alternative syntax for one-off scenarios. - Edmond - On Sat, 21 May 2011 01:19:43 +1000, Michael Turner wrote: > Anyone who thinks that I address the needs of writers in preference to > readers on this thread hasn't been reading me with much attention. > Readability is somewhat in the eye of the beholder. A lot of the > beholders > on this list are seasoned Erlang programmers. It's pretty clear what they > prefer: the way things are. > > I happen to find the indented style I propose more readable. I have also > said that I think programmers new to Erlang would tend to agree, although > without a scientific test it would be hard to establish this, I admit. > Some > day, if Erlang survives, all the eyes on it will be new, because we'll > all > pass from the scene, eventually, one way or another. So it's not as if > newbie opinion is utterly irrelevant here. > > Disagreeing with my expressed position on readability is fair. Writing > as if > I'd never expressed that position, however, is not. > > -michael turner > > On Sat, May 21, 2011 at 12:04 AM, Edmond Begumisa < > ebegumisa@REDACTED> wrote: > >> consider the needs of READERS in preference to WRITERS. >>> >> >> I found this statement nicely summed up the conflicting views on this >> thread. Very well put. And it puts the issue to rest IMO. >> >> - Edmond - >> >> >> >> On Fri, 20 May 2011 18:27:03 +1000, Richard O'Keefe >> wrote: >> >> >>> On 19/05/2011, at 4:08 AM, Michael Turner wrote: >>> >>> "Sorry, but Erlang doesn't *need* a better chance of survival." >>>> >>>> Now, wait, I'm really pretty sure that, less than a year ago, I saw >>>> both >>>> Peyton-Jones and Armstong in a video, speculating about the future of >>>> their >>>> respective favorite languages, and openly wondering what the long-term >>>> future held. >>>> >>> >>> And? Haskell is booming. They tried to avoid success and failed >>> miserably. >>> >>> In the meantime, I haven't noticed a dramatic increase in the >>> frequency >>>> of Erlang job postings, though perhaps it's gone up. However, a >>>> doubling >>>> would still leave the number small. >>>> >>> >>> That does not mean that Erlang is under threat. Come to think of it, >>> R is >>> booming >>> also. There are at least 81 mirrors of CRAN to handle the download >>> volumes. How >>> many R jobs do you see? >>> >>>> >>>> "Changing core language features that are solid,..." >>>> >>>> Except that that what I proposes fixes a weak spot (among other >>>> things): >>>> failed syntactic consistency. >>>> >>> >>> No, it leaves the *weak* spot (the absence of names in funs) along >>> and smashes the *strong* spot. >>> >>>> >>>> "... well thought out ..." >>>> >>>> Except that Joe Armstrong has just admitted (on this thread, IIRC) >>>> that >>>> the reason for the inconsistency is that they just didn't think about >>>> it at >>>> the time...." >>>> >>> >>> If you mean when "funs" were introduced, that may be so. >>> But the repeated function names were copied from languages where it >>> *WAS* >>> well thought out, rather like you probably would not fault someone for >>> designing a programming language using [] for array subscripting. >>> >>> >>>> "... and non-harmful ..." >>>> >>>> Implying that what I suggest here IS harmful? >>>> >>> >>> Yes, it is >>> It would seriously impair readability. >>> It would break several code processing tools that I use. >>> It would drastically impair the usefulness of every existing Erlang >>> book. >>> >>>> >>>> Actually not. No amount of education and experience will make >>>> repeating >>>> the function name with every clause a DRY issue, for those who find >>>> that >>>> repetition as more of an obstacle than otherwise. >>>> >>> >>> Remember always to consider the needs of READERS in preference to >>> WRITERS. >>> >>> Take Haskell, as an example. One of the advantages of Haskell is that >>> the >>> types of functions can be inferred from their bodies (as long as you >>> stick >>> to the standard language and don't use the rank 2 extension GHC >>> offers). >>> Why then do most Haskell programmers recommend writing down function >>> types >>> anyway, even though that violates DRY? >>> >>> Because although the type *is* implicit in the code, and the *compiler* >>> can figure it out, that doesn't mean it's easy for *humans*. >>> >>> If you are one of the people who find repeating function names an >>> obstacle >>> (on present evidence, a set of cardinality one), >>> - you don't have to use Erlang >>> - you can always write cases if you want >>> - you could look into LFE >>> - you could write your own preprocessor >>> >>> >>> No amount of education and experience will keep people from wondering, >>>> "Why this strange inconsistency?" >>>> >>> >>> As a matter of fact, I've known about Erlang since about a year (maybe >>> two) since the first paper >>> on it. Since well before it *had* funs, in fact. And you know, I've >>> *never* had that thought. >>> I don't experience any inconsistency. >>> >>> oAnd better documentation and training will only make more people ask >>>> that question. I didn't ask that question until I *stumbled* on the >>>> extended >>>> syntax for funs; I didn't know about it before. >>>> >>> >>> "Extended syntax for funs?" What's that? The syntax of funs is >>> described >>> in >>> chapter 7 of the reference manual, the chapter on expressions, which is >>> exactly >>> where you would expect to find it. >>> >>> The inconsistency I see is that functions are OK but funs >>> (a) do not permit a visible function name >>> -- just like Haskell, Clean, SML, CAML, &c >>> (b) begin with "fun" instead of just beginning >>> -- just like Haskell, Clean, SML, &c >>> (c) end with "end" instead of ending with a "." >>> -- the other languages I mentioned do not have any >>> -- terminator, so I usually find myself having to >>> -- wrap them in parentheses. It's quite nice not >>> -- having to do that. >>> >>> However, (b) and (c) are unsurprising because funs are >>> *expressions* and normal function definitions are not. >>> >>> If you are that upset about (a), I suggest that the inconsistency >>> should be resolved by allowing funs to have names, as I've suggested, >>> because that would fix the *other* difference between funs and >>> normal functions, which is that normal functions can be directly >>> recursive, and funs cannot. >>> >>> Your proposal to add a definition style that I find horrible for >>> normal functions fails to do anything about that *other* difference >>> between functions and funs. >>> >>> I repeat, you are urging that a *strong* spot be smashed to make >>> it consistent with a *weak* spot, which is quite the wrong way around. >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >> >> >> -- >> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ >> -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From erlang@REDACTED Fri May 20 17:45:28 2011 From: erlang@REDACTED (Joe Armstrong) Date: Fri, 20 May 2011 17:45:28 +0200 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: <3E70F4ECA6ED459C936583EE3B7301EC@srstrong.com> References: <661C1ED1-0683-435C-8BF0-5EAB2289D546@erlang-solutions.com> <3E70F4ECA6ED459C936583EE3B7301EC@srstrong.com> Message-ID: On Fri, May 20, 2011 at 9:12 AM, Steve Strong wrote: > Do you seriously think that a compiler team of a well-established and > widely used language would implement a new syntax in less than a day? The > code change itself may be relatively trivial (or a total pain in the arse, > I've not looked at the current compiler code and could believe either), but > whichever it is, it will be dwarfed by the design meetings held prior to > making the change - looking at both backward *and* forward compatibility > issues (what sort of things might this change prevent us from doing in the > future?), plus the testing that would need to be performed after. > You cannot imagine number of meetings involved - the time to change the code base is tiny compared to the arguments with project mangers etc... > > And then there's all the tools that would be broken. Emacs for one would > need work since it's syntax highlighting would now be broken. All this for > a really minor change that, judging from the responses on this list, not > that many people even want. > > Dude, this thread has gone on long enough and wasted way too much time. If > this is so important to you, then do it yourself (after all, it's less than > a days work) and publish the changes. > > Cheers, > > Steve > > -- > Steve Strong, Director, id3as > twitter.com/srstrong > > On Friday, 20 May 2011 at 07:29, Michael Turner wrote: > > Thank you, Fr?d?ric, for taking a serious look at the idea. However, I see > a few of the same unsubstantiated objections raised, with a couple more > questionable ones added. > > "- It makes it less obvious that a function has many clauses (see Steve > Davis' code)" > > WITH Steve's style of indentation. I suggested a more readable alternative, > where the "(Args)->" part has indentation column to themselves. (Curiously, > you employ my suggested indentation style yourself, below, in a supposedly > "ambiguous" code sample.) > > "- it somewhat unifies the syntax with funs, but then funs still finish > with 'end' and take no name." > > Perhaps syntax would become even more regular than you suggest. What I > propose results in a grammar more like this: > > function: > clause-list + "." > fun: > "fun" + clause-list + "end" > clause: > [optional name] (arg-list) guards -> stmt-list > > This is, if anything, more regular than the grammar is now. Yes, it > *syntactically* allows for a *different* "optional name", but so does the > current grammar; finding head mismatches *already* requires a separate step. > And I question whether it requires the parser to produce a different AST > than we get now, for parse-transform purposes. > > The above syntax also permits naming in funs. Is that so bad? As ROK has > suggested, pehaps funs ought to be allowed (limited-scope) names to > facilitate recursive definition. I happen to think it would work just as > well to re-use the keyword "fun" to refer to the fun in the process of being > defined. But there's something to be said for self-documenting recursive > funs, so I could go either way on that one. Or both ways. (I hear the moans: > "Not *another* way to do the same thing..." -- as if they were actually the > same. And as if I weren't proposing here to do things ONE way.) > > "- it creates more learning overhead if both forms are used." > > That depends on how you learn (and teach) a language. Really: how much more > page space does it require to show a slightly different way to do something? > And then there are different learner styles. After learning the basics of a > language, I tend to flip to an appendix like "syntax summary" (in BNF and > other semi-formal styles), to start exploring the meaning of different > combinatorial possibilities -- it's often one of the most clarifying and > delightful exercises I undertake. Alas, neither of the Erlang books has any > such an appendix (mandatory for a programming language primer, I would have > thought.) For me, that has made learning Erlang harder. > > "- it's not faster (compile time, might even make compiling slower)" > > You've got to be kidding. It's long been known: the time complexity of > parsing is overwhelmingly dominated by scanning. Code written in the form I > propose would have fewer tokens to scan. > > "- it doesn't make the parser code easier to maintain" > > It might, actually. See above. > > "- it's making a lot of documentation obsolete that will need to be > updated. This is common to all changes though." > > Yes, it is. Not to mention that the documentation on Erlang syntax is due > for an upgrade anyway. The first hit I get on "Erlang" and "fun" yields the > section "Syntax of funs", here: > > http://www.erlang.org/doc/programming_examples/funs.html#id59209 > > Yes, believe it: no coverage of the multi-clause case. > > "You'll be creating a hell of a lot more work ...." > > Ah, it seems almost obligatory on this thread: exaggeration asserted as > fact. Would it really require even as much as a day's work on the parser? > Yes, it would require updating documentation of Erlang syntax, but that > documentation that (see above) clearly needs a little work anyway. > > "Oh and lastly, you could also have to consider this ambiguity ...." > > It wouldn't even be an ambiguity. It would only be a weird and pointless > way to write that code. And that's IF someone wrote code like that. Well, > anybody can write crappy and confusing code that abuses any language > feature. (There it is: my own obligatory exaggeration for this thread.) Any > "obfuscated Erlang contest" would likely to whack the worst Obfuscated C out > the ballpark. (And that's no exaggeration.) > > -michael turner > > 2011/5/19 Fr?d?ric Trottier-H?bert > > Well let's take a look here. Syntax doesn't have to break old code to > change, that's a good point. > > You'll see that if you try {lists, sort}([3,2,1]), you will obtain [1,2,3]. > This basic fun syntax dates from before Erlang actually had funs (fun > M:F/A). You'll notice that it was less complex, tends to avoid verbosity and > is somewhat more readable than doing (fun lists:sort/1)([1,2,3]). Going to > the new syntax didn't break any code, didn't require old working code to be > rewritten (things still work the old way, and parametrized modules are based > on that bit of syntax) and people just ignore it if they don't need it. Yet > people did the switch from {Mod, Fun} to fun M:F/A. > > Why? Because, I figure, people generally liked the new way better: it's > faster (apparently much faster), much cleaner in intent and purposes, and > way easier to figure out that we're actually dealing with a higher order > function and not some weird concept. Plus you have to consider that in many > places, you can just use 'Var(Args)' with either form. This switch had many > wins over conciseness. > > If we try to do the same with your suggestion for the new Erlang syntax, we > can basically see that it has a few advantages: > > - reduces typing required by avoiding name repetitions > - it doesn't break existing code > - it somewhat unifies the syntax with funs, but then funs still finish with > 'end' and take no name. > > > I, however, see the following disadvantages: > > - it creates multiple standards left to personal preference > - it makes it less obvious that a function has many clauses (see Steve > Davis' code) > - it creates more learning overhead if both forms are used. {Mod,Fun} for > funs has no overhead because it's basically deprecated and nobody uses it. > - All the existing tools have to be updated to understand it -- at least > those working on source files (and this includes editors and whatnot) > > To this, you must add a multiplier damage (heh) for things it doesn't make > better: > - it's not faster (compile time, might even make compiling slower) > - it doesn't make the parser code easier to maintain > - it doesn't make maintaining code in modules easier (except for some > readability benefits) > - it's not helping people understand the language better (based on my > observations that people have no problems with the current form when it > comes to understanding) > - it's making a lot of documentation obsolete that will need to be updated. > This is common to all changes though. > > In my opinion, typing less code, even if it doesn't break compatibility, is > not worth the change. You'll be creating a hell of a lot more work if only > to get a bit more concise and consistent syntax on a thing where people > don't even agree you get better readability. > > > Oh and lastly, you could also have to consider this ambiguity -- is the > following bit of code acceptable? > > my_function > (a,b,c) -> {a,b,c}; > (a,c,b) -> {a,b,v}; > my_function > (c,b,a) -> {a,b,c}. > > > On 2011-05-19, at 09:43 AM, Michael Turner wrote: > > > "Erlang is sufficiently mature that the syntax is now very difficult to > change." > > > > Nobody has yet told me why this proposed change would break any existing > code, or why it would require any significant work on the parser. > > > -- > Fred H?bert > http://www.erlang-solutions.com > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimo+erlang-questions@REDACTED Fri May 20 17:46:48 2011 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Fri, 20 May 2011 17:46:48 +0200 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: <661C1ED1-0683-435C-8BF0-5EAB2289D546@erlang-solutions.com> <3E70F4ECA6ED459C936583EE3B7301EC@srstrong.com> Message-ID: <20110520154647.GA11740@erix.ericsson.se> On Fri, May 20, 2011 at 10:57:32PM +0900, Michael Turner wrote: > "... looking at both backward *and* forward compatibility issues (what sort > of things might this change prevent us from doing in the future?)" > > I have repeatedly asked people here what this change would break, and in > particular how it might compromise backward compatibility. Nobody has > answered, so far. Since the change amounts to the compiler silently Like you ask, you get your answers. It must be as simple as this: You ask the programmers here if this change would break any old code. Most certainly it would not, as you claim. But nobody will answer "this change is safe for all old code" because firstly you did not ask that, and secondly everybody knows that the only way to know for _sure_ is to implement the change and then see if it breaks anything. And even then all you know is that you have not found any code it breaks. Yet. But allright, I'll say it! The change does not break any old code. Happy now? But I might be wrong since I have not tested the change... And that does not make the proposed change any better. > inserting a function name during parsing at points where some IDE > environments already already insert the name literally when you type ";", > it's pretty hard to see how there could be a backward compatibility issue. > > As for forward compatibility, we have it from Joe that syntax changes hardly > every happen anyway. So if change is very unlikely to happen, forward > compatiblity isn't much of an issue either, is it? > > As for how many meetings it would take Ericsson to establish that the risk > is low/zero, well, OK, got me: I've worked as a software engineer in a > couple of large companies, so I know that these things can take time. In > fact, I remember life at one networking company where any single engineering > change order to the production system required no fewer than 25 signatures. > So you may have a point there. (Although I thought part of the point of open > source was to circumvent that kind of bureaucratic tarpit. Guess I was > wrong.) You indirectly say you think we (Erlang/OTP) are a bureaucratic tarpit. For us one point of Open Source is to get bugfixes and beta testing. We do not have to accept all suggested changes. Change without thought can be bad for any project, Open Source or not. > > "Emacs for one would need work since it's syntax highlighting would now be > broken." > > It would only be broken for any code that took advantage of the change I > suggest. Which would start out at exactly zero percent of the Erlang code > out there. As the supposed "harm" grew, well, somebody would go and modify > whatever needed to be modified, to make syntax highlighting work as it does > in Emacs already for the analogous syntax in Clojure. You understate the impact. If our Emacs mode does not support all syntax of the language, it is really broken. Also, the Vim users will be upset until that is fixed. Add to this pretty printer, debugger, evaluator, ... All should work for the would be current syntax. Leaving that to be fixed later by the community is not an option. > > "If this is so important to you ...." > > It is not that important to me (at the moment.) However, like anybody else, > I hate having my case for change twisted by others, and I hate objections to > ideas (mine and others) when the objections don't actually hold water. I think that your claim that the change is small, simple and limited does not hold water, when looking at the whole system. > > If you think the thread is a waste of *your* time, you're free to not > contribute to it. > > -michael turner > > On Fri, May 20, 2011 at 4:12 PM, Steve Strong wrote: > > > Do you seriously think that a compiler team of a well-established and > > widely used language would implement a new syntax in less than a day? The > > code change itself may be relatively trivial (or a total pain in the arse, > > I've not looked at the current compiler code and could believe either), but > > whichever it is, it will be dwarfed by the design meetings held prior to > > making the change - looking at both backward *and* forward compatibility > > issues (what sort of things might this change prevent us from doing in the > > future?), plus the testing that would need to be performed after. > > > > And then there's all the tools that would be broken. Emacs for one would > > need work since it's syntax highlighting would now be broken. All this for > > a really minor change that, judging from the responses on this list, not > > that many people even want. > > > > Dude, this thread has gone on long enough and wasted way too much time. If > > this is so important to you, then do it yourself (after all, it's less than > > a days work) and publish the changes. > > > > Cheers, > > > > Steve > > > > -- > > Steve Strong, Director, id3as > > twitter.com/srstrong > > > > On Friday, 20 May 2011 at 07:29, Michael Turner wrote: > > > > Thank you, Fr?d?ric, for taking a serious look at the idea. However, I see > > a few of the same unsubstantiated objections raised, with a couple more > > questionable ones added. > > > > "- It makes it less obvious that a function has many clauses (see Steve > > Davis' code)" > > > > WITH Steve's style of indentation. I suggested a more readable alternative, > > where the "(Args)->" part has indentation column to themselves. (Curiously, > > you employ my suggested indentation style yourself, below, in a supposedly > > "ambiguous" code sample.) > > > > "- it somewhat unifies the syntax with funs, but then funs still finish > > with 'end' and take no name." > > > > Perhaps syntax would become even more regular than you suggest. What I > > propose results in a grammar more like this: > > > > function: > > clause-list + "." > > fun: > > "fun" + clause-list + "end" > > clause: > > [optional name] (arg-list) guards -> stmt-list > > > > This is, if anything, more regular than the grammar is now. Yes, it > > *syntactically* allows for a *different* "optional name", but so does the > > current grammar; finding head mismatches *already* requires a separate step. > > And I question whether it requires the parser to produce a different AST > > than we get now, for parse-transform purposes. > > > > The above syntax also permits naming in funs. Is that so bad? As ROK has > > suggested, pehaps funs ought to be allowed (limited-scope) names to > > facilitate recursive definition. I happen to think it would work just as > > well to re-use the keyword "fun" to refer to the fun in the process of being > > defined. But there's something to be said for self-documenting recursive > > funs, so I could go either way on that one. Or both ways. (I hear the moans: > > "Not *another* way to do the same thing..." -- as if they were actually the > > same. And as if I weren't proposing here to do things ONE way.) > > > > "- it creates more learning overhead if both forms are used." > > > > That depends on how you learn (and teach) a language. Really: how much more > > page space does it require to show a slightly different way to do something? > > And then there are different learner styles. After learning the basics of a > > language, I tend to flip to an appendix like "syntax summary" (in BNF and > > other semi-formal styles), to start exploring the meaning of different > > combinatorial possibilities -- it's often one of the most clarifying and > > delightful exercises I undertake. Alas, neither of the Erlang books has any > > such an appendix (mandatory for a programming language primer, I would have > > thought.) For me, that has made learning Erlang harder. > > > > "- it's not faster (compile time, might even make compiling slower)" > > > > You've got to be kidding. It's long been known: the time complexity of > > parsing is overwhelmingly dominated by scanning. Code written in the form I > > propose would have fewer tokens to scan. > > > > "- it doesn't make the parser code easier to maintain" > > > > It might, actually. See above. > > > > "- it's making a lot of documentation obsolete that will need to be > > updated. This is common to all changes though." > > > > Yes, it is. Not to mention that the documentation on Erlang syntax is due > > for an upgrade anyway. The first hit I get on "Erlang" and "fun" yields the > > section "Syntax of funs", here: > > > > http://www.erlang.org/doc/programming_examples/funs.html#id59209 > > > > Yes, believe it: no coverage of the multi-clause case. > > > > "You'll be creating a hell of a lot more work ...." > > > > Ah, it seems almost obligatory on this thread: exaggeration asserted as > > fact. Would it really require even as much as a day's work on the parser? > > Yes, it would require updating documentation of Erlang syntax, but that > > documentation that (see above) clearly needs a little work anyway. > > > > "Oh and lastly, you could also have to consider this ambiguity ...." > > > > It wouldn't even be an ambiguity. It would only be a weird and pointless > > way to write that code. And that's IF someone wrote code like that. Well, > > anybody can write crappy and confusing code that abuses any language > > feature. (There it is: my own obligatory exaggeration for this thread.) Any > > "obfuscated Erlang contest" would likely to whack the worst Obfuscated C out > > the ballpark. (And that's no exaggeration.) > > > > -michael turner > > > > 2011/5/19 Fr?d?ric Trottier-H?bert > > > > Well let's take a look here. Syntax doesn't have to break old code to > > change, that's a good point. > > > > You'll see that if you try {lists, sort}([3,2,1]), you will obtain [1,2,3]. > > This basic fun syntax dates from before Erlang actually had funs (fun > > M:F/A). You'll notice that it was less complex, tends to avoid verbosity and > > is somewhat more readable than doing (fun lists:sort/1)([1,2,3]). Going to > > the new syntax didn't break any code, didn't require old working code to be > > rewritten (things still work the old way, and parametrized modules are based > > on that bit of syntax) and people just ignore it if they don't need it. Yet > > people did the switch from {Mod, Fun} to fun M:F/A. > > > > Why? Because, I figure, people generally liked the new way better: it's > > faster (apparently much faster), much cleaner in intent and purposes, and > > way easier to figure out that we're actually dealing with a higher order > > function and not some weird concept. Plus you have to consider that in many > > places, you can just use 'Var(Args)' with either form. This switch had many > > wins over conciseness. > > > > If we try to do the same with your suggestion for the new Erlang syntax, we > > can basically see that it has a few advantages: > > > > - reduces typing required by avoiding name repetitions > > - it doesn't break existing code > > - it somewhat unifies the syntax with funs, but then funs still finish with > > 'end' and take no name. > > > > > > I, however, see the following disadvantages: > > > > - it creates multiple standards left to personal preference > > - it makes it less obvious that a function has many clauses (see Steve > > Davis' code) > > - it creates more learning overhead if both forms are used. {Mod,Fun} for > > funs has no overhead because it's basically deprecated and nobody uses it. > > - All the existing tools have to be updated to understand it -- at least > > those working on source files (and this includes editors and whatnot) > > > > To this, you must add a multiplier damage (heh) for things it doesn't make > > better: > > - it's not faster (compile time, might even make compiling slower) > > - it doesn't make the parser code easier to maintain > > - it doesn't make maintaining code in modules easier (except for some > > readability benefits) > > - it's not helping people understand the language better (based on my > > observations that people have no problems with the current form when it > > comes to understanding) > > - it's making a lot of documentation obsolete that will need to be updated. > > This is common to all changes though. > > > > In my opinion, typing less code, even if it doesn't break compatibility, is > > not worth the change. You'll be creating a hell of a lot more work if only > > to get a bit more concise and consistent syntax on a thing where people > > don't even agree you get better readability. > > > > > > Oh and lastly, you could also have to consider this ambiguity -- is the > > following bit of code acceptable? > > > > my_function > > (a,b,c) -> {a,b,c}; > > (a,c,b) -> {a,b,v}; > > my_function > > (c,b,a) -> {a,b,c}. > > > > > > On 2011-05-19, at 09:43 AM, Michael Turner wrote: > > > > > "Erlang is sufficiently mature that the syntax is now very difficult to > > change." > > > > > > Nobody has yet told me why this proposed change would break any existing > > code, or why it would require any significant work on the parser. > > > > > > -- > > Fred H?bert > > http://www.erlang-solutions.com > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From mrtndimitrov@REDACTED Fri May 20 18:11:32 2011 From: mrtndimitrov@REDACTED (Martin Dimitrov) Date: Fri, 20 May 2011 19:11:32 +0300 Subject: [erlang-questions] erlmail problems In-Reply-To: <20110520145337.GH11203@hijacked.us> References: <4DD65A85.5000605@gmail.com> <20110520145337.GH11203@hijacked.us> Message-ID: <4DD692B4.60207@gmail.com> Thanks for the reply. I will be looking foreword to see your IMAP server and client. There are some forks of erlmail. Any idea on them? Regards, Martin On 5/20/2011 5:53 PM, Andrew Thompson wrote: > On Fri, May 20, 2011 at 03:11:49PM +0300, Martin Dimitrov wrote: >> Hi, >> >> I am trying to use erlmail as an IMAP client only. I modified the >> library to use ssl instead of gen_tcp sockets but I receive errors when >> the library is parsing the return line from googlemail: >> >> * OK Gimap ready for requests from 79.126.56.221 i9if507573yhn.157\r\n >> >> This line seems to me ok. >> Had anyone used erlmail as an IMAP client? Any advise? Other libraries? >> > I tried to play with erlmail some and I couldn't get anywhere. I was > trying the IMAP server component though, not the client. After digging > into it a little I basically wrote the whole codebase off as a loss > because I had trouble figuring out how the code was *supposed* to work, > let alone figuring out why it wasn't working. > > I don't know of an alternate IMAP client library for erlang, though. > I've been writing an IMAP server implementation for the last couple > weeks (https://github.com/Vagabond/diemap) but that's probably not much > help (its also really unfinished). I was considering eventually writing > a client to go with it, as I did with my SMTP library but if I do it'll > be a while. > > Andrew > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From erlang@REDACTED Fri May 20 18:23:57 2011 From: erlang@REDACTED (Joe Armstrong) Date: Fri, 20 May 2011 18:23:57 +0200 Subject: [erlang-questions] Advanced Erlang Subtleties In-Reply-To: <20110520034535.GA6320@mulga.csse.unimelb.edu.au> References: <20110520034535.GA6320@mulga.csse.unimelb.edu.au> Message-ID: On Fri, May 20, 2011 at 5:45 AM, Jeff Schultz wrote: > On Thu, May 19, 2011 at 11:02:35PM +0200, Joe Armstrong wrote: > > > I can see the equivalent evaluation of "250"<250 being a common > mistake, > > > and always being false is hardly useful. > > > A "<" B when A and B have different types means A is > > "less complex" than B. Lists and more complex than integers > > "250" is a list so "250"<250 is false. > Another thought I had about this was that in some languages "10" < 20 might be true, and "20" < 10 or 20 < "10" might be false. In Erlang a string (list) is always bigger (ie more complex) than an integer. A Javascript programmer might get confused here. Erlang: "12" + 1 => (exception) "12" - 1 => (exception) "12" > 2 => true "12" > 15 => true Javascript: "12" + 1 => "121" "12" - 1 => 11 "12" > 2 => true "12" > 15 => false Overloading plus to mean either plus or string concatenation is horrible - and shouldn't "-" mean string subtraction (sometimes) so "123" - 23 =>100 and "abc" - "a" => "bc" and "abc" - "c" => "ab" :-) I prefer the Erlang method - but then I'm probably somewhat biased here... This (Javascript) horrible way of doing things caused me hours of debugging - since my debugger wrote strings without the quotes so I couldn't see the difference between "123" and 123 when printed. Javascript also crashes late, and variables in closures can be changed after binding them into the closures ... and the concurrency model is ... (isn't) - but it's fun to muck around with and do things in the browser. > > Suppose I want to make a Key-Value database, where the Key can be > anything, > > including 250 and "250" to make any form of ordered tree we need a total > > order over all the keys. > > Indeed. If we can have only one built-in comparison, it needs to be > total over all values. It is a pity that Prolog's distinction between > term comparison and number comparison wasn't carried over to Erlang :-( > > > Jeff Schultz > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf.wiger@REDACTED Fri May 20 18:30:03 2011 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Fri, 20 May 2011 18:30:03 +0200 Subject: [erlang-questions] Advanced Erlang Subtleties In-Reply-To: References: <20110520034535.GA6320@mulga.csse.unimelb.edu.au> Message-ID: <7F4626BD-31C9-409B-AB56-F05B3FB8EE04@erlang-solutions.com> On 20 May 2011, at 18:23, Joe Armstrong wrote: > Javascript: > > "12" + 1 => "121" > "12" - 1 => 11 Aah, that's cute. :) A nice example of how semantics is so much more important than syntax? BR, Ulf Ulf Wiger, CTO, Erlang Solutions, Ltd. http://erlang-solutions.com From andrew@REDACTED Fri May 20 18:49:13 2011 From: andrew@REDACTED (Andrew Thompson) Date: Fri, 20 May 2011 12:49:13 -0400 Subject: [erlang-questions] erlmail problems In-Reply-To: <4DD692B4.60207@gmail.com> References: <4DD65A85.5000605@gmail.com> <20110520145337.GH11203@hijacked.us> <4DD692B4.60207@gmail.com> Message-ID: <20110520164913.GI11203@hijacked.us> On Fri, May 20, 2011 at 07:11:32PM +0300, Martin Dimitrov wrote: > Thanks for the reply. > > I will be looking foreword to see your IMAP server and client. > > There are some forks of erlmail. > > Any idea on them? I know Geoff Cant (archaelus) had a similar experience with erlmail as I did. He's the one with the fork on github. Andrew From jameschurchman@REDACTED Fri May 20 19:02:59 2011 From: jameschurchman@REDACTED (James Churchman) Date: Fri, 20 May 2011 18:02:59 +0100 Subject: [erlang-questions] Advanced Erlang Subtleties In-Reply-To: References: <20110520034535.GA6320@mulga.csse.unimelb.edu.au> Message-ID: yes this is where i think erlang really gets the balance correct, being dynamically typed ( so far less repetitive defining types where the type is either obvious or does not matter and is just begin "messaged" threw .. tho i know other people are strongly in favour of static typing) but not Loosely Typed so avoids the huge amounts of ambiguity like what happens when you "add" or "subtract" different types as does JS, leading to the bug showing up a huge distance way from the code that was at fault.. unfortunately JS also has hundreds of faults & bugs ( around 270 at my count ;-) ) in the original implementation that due to a big of a chicken / egg scenario cant really ever be changed :-) things like "crashing late" come from the fact that early versions had no error handling at all! ( eg no try catch ) >A nice example of how semantics is so much more important than syntax? yes and shows that purely putting new syntax's onto an existing language only aid developer productivity & readability a bit and generally don't make the code (much) more reliable > On Fri, May 20, 2011 at 5:45 AM, Jeff Schultz wrote: > On Thu, May 19, 2011 at 11:02:35PM +0200, Joe Armstrong wrote: > > > I can see the equivalent evaluation of "250"<250 being a common mistake, > > > and always being false is hardly useful. > > > A "<" B when A and B have different types means A is > > "less complex" than B. Lists and more complex than integers > > "250" is a list so "250"<250 is false. > > Another thought I had about this was that in some languages > "10" < 20 might be true, and "20" < 10 or 20 < "10" might be false. > > In Erlang a string (list) is always bigger (ie more complex) than an integer. > > A Javascript programmer might get confused here. > > Erlang: > > "12" + 1 => (exception) > "12" - 1 => (exception) > "12" > 2 => true > "12" > 15 => true > > Javascript: > > "12" + 1 => "121" > "12" - 1 => 11 > "12" > 2 => true > "12" > 15 => false > > Overloading plus to mean either plus or string concatenation is > horrible - and shouldn't "-" mean string subtraction (sometimes) > > so "123" - 23 =>100 and "abc" - "a" => "bc" and "abc" - "c" => "ab" > :-) > > I prefer the Erlang method - but then I'm probably somewhat biased here... > > This (Javascript) horrible way of doing things caused me > hours of debugging - since my debugger wrote strings without > the quotes so I couldn't see the difference between "123" and 123 > when printed. > > Javascript also crashes late, and variables in closures > can be changed after binding them into the closures ... and the > concurrency model is ... (isn't) - but it's fun to muck around with > and do things in the browser. > > > > Suppose I want to make a Key-Value database, where the Key can be anything, > > including 250 and "250" to make any form of ordered tree we need a total > > order over all the keys. > > Indeed. If we can have only one built-in comparison, it needs to be > total over all values. It is a pity that Prolog's distinction between > term comparison and number comparison wasn't carried over to Erlang :-( > > > Jeff Schultz > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebegumisa@REDACTED Fri May 20 19:16:53 2011 From: ebegumisa@REDACTED (Edmond Begumisa) Date: Sat, 21 May 2011 03:16:53 +1000 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: <661C1ED1-0683-435C-8BF0-5EAB2289D546@erlang-solutions.com> <3E70F4ECA6ED459C936583EE3B7301EC@srstrong.com> Message-ID: On Fri, 20 May 2011 23:57:32 +1000, Michael Turner wrote: > "... looking at both backward *and* forward compatibility issues (what > sort > of things might this change prevent us from doing in the future?)" > > I have repeatedly asked people here what this change would break, and in > particular how it might compromise backward compatibility. Nobody has > answered, so far. Since the change amounts to the compiler silently > inserting a function name during parsing at points where some IDE > environments already already insert the name literally when you type ";", > it's pretty hard to see how there could be a backward compatibility > issue. > > As for forward compatibility, we have it from Joe that syntax changes > hardly > every happen anyway. So if change is very unlikely to happen, forward > compatiblity isn't much of an issue either, is it? > > As for how many meetings it would take Ericsson to establish that the > risk > is low/zero, well, OK, got me: I've worked as a software engineer in a > couple of large companies, so I know that these things can take time. In > fact, I remember life at one networking company where any single > engineering > change order to the production system required no fewer than 25 > signatures. > So you may have a point there. (Although I thought part of the point of > open > source was to circumvent that kind of bureaucratic tarpit. Guess I was > wrong.) One of the main motivations for a private company to open-source their proprietary code is to have *others* improve it not just have others make *suggestions* for its improvement. Suggestions can be obtained even with closed source software. Erlang has the EEP system for this. As others have suggested, if you really feel strongly on this prove everyone wrong! Write up an EEP. Show everyone that their fears are exaggerated. Supply a patch so we can see for ourselves how cool it would be! It wouldn't be the first time a skeptical community has been eventually convinced. But there's a problem with this... > "Emacs for one would need work since it's syntax highlighting would now > be > broken." > > It would only be broken for any code that took advantage of the change I > suggest. Which would start out at exactly zero percent of the Erlang code > out there. As the supposed "harm" grew, well, somebody would go and > modify > whatever needed to be modified, to make syntax highlighting work as it > does > in Emacs already for the analogous syntax in Clojure. > > "If this is so important to you ...." > > It is not that important to me (at the moment.) ... it's not that important to you. You have better things to do correct? At the moment it's just a minor inconvenience, right? So why let it get to you? > However, like anybody else, > I hate having my case for change twisted by others, and I hate > objections to > ideas (mine and others) when the objections don't actually hold water. So let me understand this... The change is not _that_ important to you (not important enough to effect it yourself.) But you'll happily imply that others should effect the change (which is fair enough BTW -- others may be far more intimate with the code that would need changing.) But when those others (those both more intimate with the code and whom you are essentially asking to make the change), when _they_ tell you that they don't see the need for it, and give you _their_ reasons for not wanting to effect it -- you say hogwash! All on a change that's not that important to you! That position is a little unfair don't you think? - Edmond - > If you think the thread is a waste of *your* time, you're free to not > contribute to it. > > -michael turner > > On Fri, May 20, 2011 at 4:12 PM, Steve Strong wrote: > >> Do you seriously think that a compiler team of a well-established and >> widely used language would implement a new syntax in less than a day? >> The >> code change itself may be relatively trivial (or a total pain in the >> arse, >> I've not looked at the current compiler code and could believe either), >> but >> whichever it is, it will be dwarfed by the design meetings held prior to >> making the change - looking at both backward *and* forward compatibility >> issues (what sort of things might this change prevent us from doing in >> the >> future?), plus the testing that would need to be performed after. >> >> And then there's all the tools that would be broken. Emacs for one >> would >> need work since it's syntax highlighting would now be broken. All this >> for >> a really minor change that, judging from the responses on this list, not >> that many people even want. >> >> Dude, this thread has gone on long enough and wasted way too much >> time. If >> this is so important to you, then do it yourself (after all, it's less >> than >> a days work) and publish the changes. >> >> Cheers, >> >> Steve >> >> -- >> Steve Strong, Director, id3as >> twitter.com/srstrong >> >> On Friday, 20 May 2011 at 07:29, Michael Turner wrote: >> >> Thank you, Fr?d?ric, for taking a serious look at the idea. However, I >> see >> a few of the same unsubstantiated objections raised, with a couple more >> questionable ones added. >> >> "- It makes it less obvious that a function has many clauses (see Steve >> Davis' code)" >> >> WITH Steve's style of indentation. I suggested a more readable >> alternative, >> where the "(Args)->" part has indentation column to themselves. >> (Curiously, >> you employ my suggested indentation style yourself, below, in a >> supposedly >> "ambiguous" code sample.) >> >> "- it somewhat unifies the syntax with funs, but then funs still finish >> with 'end' and take no name." >> >> Perhaps syntax would become even more regular than you suggest. What I >> propose results in a grammar more like this: >> >> function: >> clause-list + "." >> fun: >> "fun" + clause-list + "end" >> clause: >> [optional name] (arg-list) guards -> stmt-list >> >> This is, if anything, more regular than the grammar is now. Yes, it >> *syntactically* allows for a *different* "optional name", but so does >> the >> current grammar; finding head mismatches *already* requires a separate >> step. >> And I question whether it requires the parser to produce a different AST >> than we get now, for parse-transform purposes. >> >> The above syntax also permits naming in funs. Is that so bad? As ROK has >> suggested, pehaps funs ought to be allowed (limited-scope) names to >> facilitate recursive definition. I happen to think it would work just as >> well to re-use the keyword "fun" to refer to the fun in the process of >> being >> defined. But there's something to be said for self-documenting recursive >> funs, so I could go either way on that one. Or both ways. (I hear the >> moans: >> "Not *another* way to do the same thing..." -- as if they were actually >> the >> same. And as if I weren't proposing here to do things ONE way.) >> >> "- it creates more learning overhead if both forms are used." >> >> That depends on how you learn (and teach) a language. Really: how much >> more >> page space does it require to show a slightly different way to do >> something? >> And then there are different learner styles. After learning the basics >> of a >> language, I tend to flip to an appendix like "syntax summary" (in BNF >> and >> other semi-formal styles), to start exploring the meaning of different >> combinatorial possibilities -- it's often one of the most clarifying and >> delightful exercises I undertake. Alas, neither of the Erlang books has >> any >> such an appendix (mandatory for a programming language primer, I would >> have >> thought.) For me, that has made learning Erlang harder. >> >> "- it's not faster (compile time, might even make compiling slower)" >> >> You've got to be kidding. It's long been known: the time complexity of >> parsing is overwhelmingly dominated by scanning. Code written in the >> form I >> propose would have fewer tokens to scan. >> >> "- it doesn't make the parser code easier to maintain" >> >> It might, actually. See above. >> >> "- it's making a lot of documentation obsolete that will need to be >> updated. This is common to all changes though." >> >> Yes, it is. Not to mention that the documentation on Erlang syntax is >> due >> for an upgrade anyway. The first hit I get on "Erlang" and "fun" yields >> the >> section "Syntax of funs", here: >> >> http://www.erlang.org/doc/programming_examples/funs.html#id59209 >> >> Yes, believe it: no coverage of the multi-clause case. >> >> "You'll be creating a hell of a lot more work ...." >> >> Ah, it seems almost obligatory on this thread: exaggeration asserted as >> fact. Would it really require even as much as a day's work on the >> parser? >> Yes, it would require updating documentation of Erlang syntax, but that >> documentation that (see above) clearly needs a little work anyway. >> >> "Oh and lastly, you could also have to consider this ambiguity ...." >> >> It wouldn't even be an ambiguity. It would only be a weird and pointless >> way to write that code. And that's IF someone wrote code like that. >> Well, >> anybody can write crappy and confusing code that abuses any language >> feature. (There it is: my own obligatory exaggeration for this thread.) >> Any >> "obfuscated Erlang contest" would likely to whack the worst Obfuscated >> C out >> the ballpark. (And that's no exaggeration.) >> >> -michael turner >> >> 2011/5/19 Fr?d?ric Trottier-H?bert >> >> Well let's take a look here. Syntax doesn't have to break old code to >> change, that's a good point. >> >> You'll see that if you try {lists, sort}([3,2,1]), you will obtain >> [1,2,3]. >> This basic fun syntax dates from before Erlang actually had funs (fun >> M:F/A). You'll notice that it was less complex, tends to avoid >> verbosity and >> is somewhat more readable than doing (fun lists:sort/1)([1,2,3]). Going >> to >> the new syntax didn't break any code, didn't require old working code >> to be >> rewritten (things still work the old way, and parametrized modules are >> based >> on that bit of syntax) and people just ignore it if they don't need >> it. Yet >> people did the switch from {Mod, Fun} to fun M:F/A. >> >> Why? Because, I figure, people generally liked the new way better: it's >> faster (apparently much faster), much cleaner in intent and purposes, >> and >> way easier to figure out that we're actually dealing with a higher order >> function and not some weird concept. Plus you have to consider that in >> many >> places, you can just use 'Var(Args)' with either form. This switch had >> many >> wins over conciseness. >> >> If we try to do the same with your suggestion for the new Erlang >> syntax, we >> can basically see that it has a few advantages: >> >> - reduces typing required by avoiding name repetitions >> - it doesn't break existing code >> - it somewhat unifies the syntax with funs, but then funs still finish >> with >> 'end' and take no name. >> >> >> I, however, see the following disadvantages: >> >> - it creates multiple standards left to personal preference >> - it makes it less obvious that a function has many clauses (see Steve >> Davis' code) >> - it creates more learning overhead if both forms are used. {Mod,Fun} >> for >> funs has no overhead because it's basically deprecated and nobody uses >> it. >> - All the existing tools have to be updated to understand it -- at least >> those working on source files (and this includes editors and whatnot) >> >> To this, you must add a multiplier damage (heh) for things it doesn't >> make >> better: >> - it's not faster (compile time, might even make compiling slower) >> - it doesn't make the parser code easier to maintain >> - it doesn't make maintaining code in modules easier (except for some >> readability benefits) >> - it's not helping people understand the language better (based on my >> observations that people have no problems with the current form when it >> comes to understanding) >> - it's making a lot of documentation obsolete that will need to be >> updated. >> This is common to all changes though. >> >> In my opinion, typing less code, even if it doesn't break >> compatibility, is >> not worth the change. You'll be creating a hell of a lot more work if >> only >> to get a bit more concise and consistent syntax on a thing where people >> don't even agree you get better readability. >> >> >> Oh and lastly, you could also have to consider this ambiguity -- is the >> following bit of code acceptable? >> >> my_function >> (a,b,c) -> {a,b,c}; >> (a,c,b) -> {a,b,v}; >> my_function >> (c,b,a) -> {a,b,c}. >> >> >> On 2011-05-19, at 09:43 AM, Michael Turner wrote: >> >> > "Erlang is sufficiently mature that the syntax is now very difficult >> to >> change." >> > >> > Nobody has yet told me why this proposed change would break any >> existing >> code, or why it would require any significant work on the parser. >> >> >> -- >> Fred H?bert >> http://www.erlang-solutions.com >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From andy.kriger@REDACTED Fri May 20 19:29:58 2011 From: andy.kriger@REDACTED (Andy Kriger) Date: Fri, 20 May 2011 13:29:58 -0400 Subject: [erlang-questions] What are the "Most valuable libraries?"...and a few other questions In-Reply-To: <4DD61144.3060903@gmail.com> References: <20110517142848.GA9263@erix.ericsson.se> <230D6DBF-EE90-475F-A973-DF0E7B71EF19@cs.otago.ac.nz> <4DD311FF.2090402@gmail.com> <1B641F41-EE9F-40BC-B0CB-7AAD5C26D750@cs.otago.ac.nz> <4DD61144.3060903@gmail.com> Message-ID: On Fri, May 20, 2011 at 2:59 AM, Michael Truog wrote: > On 05/19/2011 11:10 PM, Richard O'Keefe wrote: >>> On Tue, May 17, 2011 at 5:25 PM, Todd wrote: >>> 4b. Side note: is anyone concerned about Akka/Typesafe stealing mindshare? >> Having read Williamson's "Legion of Space" series, I would feel rather >> unhappy using AKKA (:-). > > Not sure if you saw it, but there now is pykka (for python, at https://github.com/jodal/pykka ). > > Even if these and other libraries (jetlang is the basis for akka, kilim which came before it, in the Java world, etc.) support message passing based scheduling of light-weight processes in a way that facilitates creating Actors, the libraries are unlikely to perform as well as Erlang because: > - The amount of research/development that has gone into Erlang > - The process-based garbage collection which can not be found through a message passing library > > Ok, even if the message based scheduling of light-weight processes is as efficient (comparable) to Erlang (ignoring garbage collection problems), a library will not give you code-level fault-tolerance (unless you go through a lot of painful development with custom code that lacks testing and increases the complexity of your codebase). ?So, I do not think there will be an Erlang replacement anytime soon. > _______________________________________________ If anything Akka will expose more Java folks to Erlang concepts and potentially draw people looking for a way out of neo-COBOL. From michael.eugene.turner@REDACTED Fri May 20 19:51:22 2011 From: michael.eugene.turner@REDACTED (Michael Turner) Date: Sat, 21 May 2011 02:51:22 +0900 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: <661C1ED1-0683-435C-8BF0-5EAB2289D546@erlang-solutions.com> <3E70F4ECA6ED459C936583EE3B7301EC@srstrong.com> Message-ID: "But you'll happily imply that others should effect the change " Oh, no, I have given up on that. I can now see why it's not going to happen. "... when _they_ tell you that they don't see the need for it, and give you _their_ reasons for not wanting to effect it -- you say hogwash! All on a change that's not that important to you!" For some strange reason, it IS important to me when people misrepresent my positions. As you just did. >From the very first post I made on this thread, I talked about readability. You responded as if I had prioritized writeability over readability. Is that fair? Have you even *read* the first post I made on this? (Which pretty much laid out my entire case.) Or do you consider that a dispensable step in coming to a judgment of my position? Here's the core paragraph from that first post: "It's also less to type and to read, which is consistent with the DRY principle ("Don't Repeat Yourself"). And it lends itself to reading a function definition as a set of cases. I think for Erlang newbies, it should therefore would be preferred: it helps underscore the pattern-matching style of Erlang function invocation." That's an argument in which readability weighs slightly more, isn't it? -michael turner On Sat, May 21, 2011 at 2:16 AM, Edmond Begumisa < ebegumisa@REDACTED> wrote: > On Fri, 20 May 2011 23:57:32 +1000, Michael Turner < > michael.eugene.turner@REDACTED> wrote: > > "... looking at both backward *and* forward compatibility issues (what >> sort >> >> of things might this change prevent us from doing in the future?)" >> >> I have repeatedly asked people here what this change would break, and in >> particular how it might compromise backward compatibility. Nobody has >> answered, so far. Since the change amounts to the compiler silently >> inserting a function name during parsing at points where some IDE >> environments already already insert the name literally when you type ";", >> it's pretty hard to see how there could be a backward compatibility issue. >> >> As for forward compatibility, we have it from Joe that syntax changes >> hardly >> every happen anyway. So if change is very unlikely to happen, forward >> compatiblity isn't much of an issue either, is it? >> >> As for how many meetings it would take Ericsson to establish that the risk >> is low/zero, well, OK, got me: I've worked as a software engineer in a >> couple of large companies, so I know that these things can take time. In >> fact, I remember life at one networking company where any single >> engineering >> change order to the production system required no fewer than 25 >> signatures. >> So you may have a point there. (Although I thought part of the point of >> open >> source was to circumvent that kind of bureaucratic tarpit. Guess I was >> wrong.) >> > > One of the main motivations for a private company to open-source their > proprietary code is to have *others* improve it not just have others make > *suggestions* for its improvement. Suggestions can be obtained even with > closed source software. > > Erlang has the EEP system for this. As others have suggested, if you really > feel strongly on this prove everyone wrong! Write up an EEP. Show everyone > that their fears are exaggerated. Supply a patch so we can see for ourselves > how cool it would be! It wouldn't be the first time a skeptical community > has been eventually convinced. > > But there's a problem with this... > > > "Emacs for one would need work since it's syntax highlighting would now be >> broken." >> >> It would only be broken for any code that took advantage of the change I >> suggest. Which would start out at exactly zero percent of the Erlang code >> out there. As the supposed "harm" grew, well, somebody would go and modify >> whatever needed to be modified, to make syntax highlighting work as it >> does >> in Emacs already for the analogous syntax in Clojure. >> >> "If this is so important to you ...." >> >> It is not that important to me (at the moment.) >> > > ... it's not that important to you. You have better things to do correct? > At the moment it's just a minor inconvenience, right? So why let it get to > you? > > > However, like anybody else, >> I hate having my case for change twisted by others, and I hate objections >> to >> ideas (mine and others) when the objections don't actually hold water. >> > > So let me understand this... > > The change is not _that_ important to you (not important enough to effect > it yourself.) But you'll happily imply that others should effect the change > (which is fair enough BTW -- others may be far more intimate with the code > that would need changing.) But when those others (those both more intimate > with the code and whom you are essentially asking to make the change), when > _they_ tell you that they don't see the need for it, and give you _their_ > reasons for not wanting to effect it -- you say hogwash! All on a change > that's not that important to you! > > That position is a little unfair don't you think? > > - Edmond - > > > > > If you think the thread is a waste of *your* time, you're free to not >> contribute to it. >> >> -michael turner >> >> On Fri, May 20, 2011 at 4:12 PM, Steve Strong wrote: >> >> Do you seriously think that a compiler team of a well-established and >>> widely used language would implement a new syntax in less than a day? The >>> code change itself may be relatively trivial (or a total pain in the >>> arse, >>> I've not looked at the current compiler code and could believe either), >>> but >>> whichever it is, it will be dwarfed by the design meetings held prior to >>> making the change - looking at both backward *and* forward compatibility >>> issues (what sort of things might this change prevent us from doing in >>> the >>> future?), plus the testing that would need to be performed after. >>> >>> And then there's all the tools that would be broken. Emacs for one would >>> need work since it's syntax highlighting would now be broken. All this >>> for >>> a really minor change that, judging from the responses on this list, not >>> that many people even want. >>> >>> Dude, this thread has gone on long enough and wasted way too much time. >>> If >>> this is so important to you, then do it yourself (after all, it's less >>> than >>> a days work) and publish the changes. >>> >>> Cheers, >>> >>> Steve >>> >>> -- >>> Steve Strong, Director, id3as >>> twitter.com/srstrong >>> >>> On Friday, 20 May 2011 at 07:29, Michael Turner wrote: >>> >>> Thank you, Fr?d?ric, for taking a serious look at the idea. However, I >>> see >>> a few of the same unsubstantiated objections raised, with a couple more >>> questionable ones added. >>> >>> "- It makes it less obvious that a function has many clauses (see Steve >>> Davis' code)" >>> >>> WITH Steve's style of indentation. I suggested a more readable >>> alternative, >>> where the "(Args)->" part has indentation column to themselves. >>> (Curiously, >>> you employ my suggested indentation style yourself, below, in a >>> supposedly >>> "ambiguous" code sample.) >>> >>> "- it somewhat unifies the syntax with funs, but then funs still finish >>> with 'end' and take no name." >>> >>> Perhaps syntax would become even more regular than you suggest. What I >>> propose results in a grammar more like this: >>> >>> function: >>> clause-list + "." >>> fun: >>> "fun" + clause-list + "end" >>> clause: >>> [optional name] (arg-list) guards -> stmt-list >>> >>> This is, if anything, more regular than the grammar is now. Yes, it >>> *syntactically* allows for a *different* "optional name", but so does the >>> current grammar; finding head mismatches *already* requires a separate >>> step. >>> And I question whether it requires the parser to produce a different AST >>> than we get now, for parse-transform purposes. >>> >>> The above syntax also permits naming in funs. Is that so bad? As ROK has >>> suggested, pehaps funs ought to be allowed (limited-scope) names to >>> facilitate recursive definition. I happen to think it would work just as >>> well to re-use the keyword "fun" to refer to the fun in the process of >>> being >>> defined. But there's something to be said for self-documenting recursive >>> funs, so I could go either way on that one. Or both ways. (I hear the >>> moans: >>> "Not *another* way to do the same thing..." -- as if they were actually >>> the >>> same. And as if I weren't proposing here to do things ONE way.) >>> >>> "- it creates more learning overhead if both forms are used." >>> >>> That depends on how you learn (and teach) a language. Really: how much >>> more >>> page space does it require to show a slightly different way to do >>> something? >>> And then there are different learner styles. After learning the basics of >>> a >>> language, I tend to flip to an appendix like "syntax summary" (in BNF and >>> other semi-formal styles), to start exploring the meaning of different >>> combinatorial possibilities -- it's often one of the most clarifying and >>> delightful exercises I undertake. Alas, neither of the Erlang books has >>> any >>> such an appendix (mandatory for a programming language primer, I would >>> have >>> thought.) For me, that has made learning Erlang harder. >>> >>> "- it's not faster (compile time, might even make compiling slower)" >>> >>> You've got to be kidding. It's long been known: the time complexity of >>> parsing is overwhelmingly dominated by scanning. Code written in the form >>> I >>> propose would have fewer tokens to scan. >>> >>> "- it doesn't make the parser code easier to maintain" >>> >>> It might, actually. See above. >>> >>> "- it's making a lot of documentation obsolete that will need to be >>> updated. This is common to all changes though." >>> >>> Yes, it is. Not to mention that the documentation on Erlang syntax is due >>> for an upgrade anyway. The first hit I get on "Erlang" and "fun" yields >>> the >>> section "Syntax of funs", here: >>> >>> http://www.erlang.org/doc/programming_examples/funs.html#id59209 >>> >>> Yes, believe it: no coverage of the multi-clause case. >>> >>> "You'll be creating a hell of a lot more work ...." >>> >>> Ah, it seems almost obligatory on this thread: exaggeration asserted as >>> fact. Would it really require even as much as a day's work on the parser? >>> Yes, it would require updating documentation of Erlang syntax, but that >>> documentation that (see above) clearly needs a little work anyway. >>> >>> "Oh and lastly, you could also have to consider this ambiguity ...." >>> >>> It wouldn't even be an ambiguity. It would only be a weird and pointless >>> way to write that code. And that's IF someone wrote code like that. Well, >>> anybody can write crappy and confusing code that abuses any language >>> feature. (There it is: my own obligatory exaggeration for this thread.) >>> Any >>> "obfuscated Erlang contest" would likely to whack the worst Obfuscated C >>> out >>> the ballpark. (And that's no exaggeration.) >>> >>> -michael turner >>> >>> 2011/5/19 Fr?d?ric Trottier-H?bert >>> >>> Well let's take a look here. Syntax doesn't have to break old code to >>> change, that's a good point. >>> >>> You'll see that if you try {lists, sort}([3,2,1]), you will obtain >>> [1,2,3]. >>> This basic fun syntax dates from before Erlang actually had funs (fun >>> M:F/A). You'll notice that it was less complex, tends to avoid verbosity >>> and >>> is somewhat more readable than doing (fun lists:sort/1)([1,2,3]). Going >>> to >>> the new syntax didn't break any code, didn't require old working code to >>> be >>> rewritten (things still work the old way, and parametrized modules are >>> based >>> on that bit of syntax) and people just ignore it if they don't need it. >>> Yet >>> people did the switch from {Mod, Fun} to fun M:F/A. >>> >>> Why? Because, I figure, people generally liked the new way better: it's >>> faster (apparently much faster), much cleaner in intent and purposes, and >>> way easier to figure out that we're actually dealing with a higher order >>> function and not some weird concept. Plus you have to consider that in >>> many >>> places, you can just use 'Var(Args)' with either form. This switch had >>> many >>> wins over conciseness. >>> >>> If we try to do the same with your suggestion for the new Erlang syntax, >>> we >>> can basically see that it has a few advantages: >>> >>> - reduces typing required by avoiding name repetitions >>> - it doesn't break existing code >>> - it somewhat unifies the syntax with funs, but then funs still finish >>> with >>> 'end' and take no name. >>> >>> >>> I, however, see the following disadvantages: >>> >>> - it creates multiple standards left to personal preference >>> - it makes it less obvious that a function has many clauses (see Steve >>> Davis' code) >>> - it creates more learning overhead if both forms are used. {Mod,Fun} for >>> funs has no overhead because it's basically deprecated and nobody uses >>> it. >>> - All the existing tools have to be updated to understand it -- at least >>> those working on source files (and this includes editors and whatnot) >>> >>> To this, you must add a multiplier damage (heh) for things it doesn't >>> make >>> better: >>> - it's not faster (compile time, might even make compiling slower) >>> - it doesn't make the parser code easier to maintain >>> - it doesn't make maintaining code in modules easier (except for some >>> readability benefits) >>> - it's not helping people understand the language better (based on my >>> observations that people have no problems with the current form when it >>> comes to understanding) >>> - it's making a lot of documentation obsolete that will need to be >>> updated. >>> This is common to all changes though. >>> >>> In my opinion, typing less code, even if it doesn't break compatibility, >>> is >>> not worth the change. You'll be creating a hell of a lot more work if >>> only >>> to get a bit more concise and consistent syntax on a thing where people >>> don't even agree you get better readability. >>> >>> >>> Oh and lastly, you could also have to consider this ambiguity -- is the >>> following bit of code acceptable? >>> >>> my_function >>> (a,b,c) -> {a,b,c}; >>> (a,c,b) -> {a,b,v}; >>> my_function >>> (c,b,a) -> {a,b,c}. >>> >>> >>> On 2011-05-19, at 09:43 AM, Michael Turner wrote: >>> >>> > "Erlang is sufficiently mature that the syntax is now very difficult to >>> change." >>> > >>> > Nobody has yet told me why this proposed change would break any >>> existing >>> code, or why it would require any significant work on the parser. >>> >>> >>> -- >>> Fred H?bert >>> http://www.erlang-solutions.com >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >>> >>> > > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.eugene.turner@REDACTED Fri May 20 20:06:08 2011 From: michael.eugene.turner@REDACTED (Michael Turner) Date: Sat, 21 May 2011 03:06:08 +0900 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: <20110520154647.GA11740@erix.ericsson.se> References: <661C1ED1-0683-435C-8BF0-5EAB2289D546@erlang-solutions.com> <3E70F4ECA6ED459C936583EE3B7301EC@srstrong.com> <20110520154647.GA11740@erix.ericsson.se> Message-ID: "You indirectly say you think we (Erlang/OTP) are a bureaucratic tarpit." It's more like Joe's comment made me think that Erlang/OTP has to live in such a tarpit. I've lived in those as a programmer, it was hellish, so I can sympathize, if in fact that's anything like your situation. But it seems I misinterpreted him. With that, I give up. Oh wait, also this: I really apologize if any of you chose to waste time on this thread. I'm sorry for making you do that. It's really all my fault. -michael turner On Sat, May 21, 2011 at 12:46 AM, Raimo Niskanen < raimo+erlang-questions@REDACTED> wrote: > On Fri, May 20, 2011 at 10:57:32PM +0900, Michael Turner wrote: > > "... looking at both backward *and* forward compatibility issues (what > sort > > of things might this change prevent us from doing in the future?)" > > > > I have repeatedly asked people here what this change would break, and in > > particular how it might compromise backward compatibility. Nobody has > > answered, so far. Since the change amounts to the compiler silently > > Like you ask, you get your answers. > > It must be as simple as this: You ask the programmers here if this change > would break any old code. Most certainly it would not, as you claim. > But nobody will answer "this change is safe for all old code" because > firstly you did not ask that, and secondly everybody knows that the only > way to know for _sure_ is to implement the change and then see if it breaks > anything. And even then all you know is that you have not found any code > it breaks. Yet. > > But allright, I'll say it! The change does not break any old code. > Happy now? But I might be wrong since I have not tested the change... > > And that does not make the proposed change any better. > > > inserting a function name during parsing at points where some IDE > > environments already already insert the name literally when you type ";", > > it's pretty hard to see how there could be a backward compatibility > issue. > > > > As for forward compatibility, we have it from Joe that syntax changes > hardly > > every happen anyway. So if change is very unlikely to happen, forward > > compatiblity isn't much of an issue either, is it? > > > > As for how many meetings it would take Ericsson to establish that the > risk > > is low/zero, well, OK, got me: I've worked as a software engineer in a > > couple of large companies, so I know that these things can take time. In > > fact, I remember life at one networking company where any single > engineering > > change order to the production system required no fewer than 25 > signatures. > > So you may have a point there. (Although I thought part of the point of > open > > source was to circumvent that kind of bureaucratic tarpit. Guess I was > > wrong.) > > You indirectly say you think we (Erlang/OTP) are a bureaucratic tarpit. > > For us one point of Open Source is to get bugfixes and beta testing. > We do not have to accept all suggested changes. Change without > thought can be bad for any project, Open Source or not. > > > > > "Emacs for one would need work since it's syntax highlighting would now > be > > broken." > > > > It would only be broken for any code that took advantage of the change I > > suggest. Which would start out at exactly zero percent of the Erlang code > > out there. As the supposed "harm" grew, well, somebody would go and > modify > > whatever needed to be modified, to make syntax highlighting work as it > does > > in Emacs already for the analogous syntax in Clojure. > > You understate the impact. If our Emacs mode does not support all syntax > of the language, it is really broken. Also, the Vim users will be upset > until that is fixed. Add to this pretty printer, debugger, evaluator, ... > All should work for the would be current syntax. Leaving that to be fixed > later by the community is not an option. > > > > > "If this is so important to you ...." > > > > It is not that important to me (at the moment.) However, like anybody > else, > > I hate having my case for change twisted by others, and I hate objections > to > > ideas (mine and others) when the objections don't actually hold water. > > I think that your claim that the change is small, simple and limited > does not hold water, when looking at the whole system. > > > > > If you think the thread is a waste of *your* time, you're free to not > > contribute to it. > > > > -michael turner > > > > On Fri, May 20, 2011 at 4:12 PM, Steve Strong > wrote: > > > > > Do you seriously think that a compiler team of a well-established and > > > widely used language would implement a new syntax in less than a day? > The > > > code change itself may be relatively trivial (or a total pain in the > arse, > > > I've not looked at the current compiler code and could believe either), > but > > > whichever it is, it will be dwarfed by the design meetings held prior > to > > > making the change - looking at both backward *and* forward > compatibility > > > issues (what sort of things might this change prevent us from doing in > the > > > future?), plus the testing that would need to be performed after. > > > > > > And then there's all the tools that would be broken. Emacs for one > would > > > need work since it's syntax highlighting would now be broken. All this > for > > > a really minor change that, judging from the responses on this list, > not > > > that many people even want. > > > > > > Dude, this thread has gone on long enough and wasted way too much time. > If > > > this is so important to you, then do it yourself (after all, it's less > than > > > a days work) and publish the changes. > > > > > > Cheers, > > > > > > Steve > > > > > > -- > > > Steve Strong, Director, id3as > > > twitter.com/srstrong > > > > > > On Friday, 20 May 2011 at 07:29, Michael Turner wrote: > > > > > > Thank you, Fr?d?ric, for taking a serious look at the idea. However, I > see > > > a few of the same unsubstantiated objections raised, with a couple more > > > questionable ones added. > > > > > > "- It makes it less obvious that a function has many clauses (see Steve > > > Davis' code)" > > > > > > WITH Steve's style of indentation. I suggested a more readable > alternative, > > > where the "(Args)->" part has indentation column to themselves. > (Curiously, > > > you employ my suggested indentation style yourself, below, in a > supposedly > > > "ambiguous" code sample.) > > > > > > "- it somewhat unifies the syntax with funs, but then funs still finish > > > with 'end' and take no name." > > > > > > Perhaps syntax would become even more regular than you suggest. What I > > > propose results in a grammar more like this: > > > > > > function: > > > clause-list + "." > > > fun: > > > "fun" + clause-list + "end" > > > clause: > > > [optional name] (arg-list) guards -> stmt-list > > > > > > This is, if anything, more regular than the grammar is now. Yes, it > > > *syntactically* allows for a *different* "optional name", but so does > the > > > current grammar; finding head mismatches *already* requires a separate > step. > > > And I question whether it requires the parser to produce a different > AST > > > than we get now, for parse-transform purposes. > > > > > > The above syntax also permits naming in funs. Is that so bad? As ROK > has > > > suggested, pehaps funs ought to be allowed (limited-scope) names to > > > facilitate recursive definition. I happen to think it would work just > as > > > well to re-use the keyword "fun" to refer to the fun in the process of > being > > > defined. But there's something to be said for self-documenting > recursive > > > funs, so I could go either way on that one. Or both ways. (I hear the > moans: > > > "Not *another* way to do the same thing..." -- as if they were actually > the > > > same. And as if I weren't proposing here to do things ONE way.) > > > > > > "- it creates more learning overhead if both forms are used." > > > > > > That depends on how you learn (and teach) a language. Really: how much > more > > > page space does it require to show a slightly different way to do > something? > > > And then there are different learner styles. After learning the basics > of a > > > language, I tend to flip to an appendix like "syntax summary" (in BNF > and > > > other semi-formal styles), to start exploring the meaning of different > > > combinatorial possibilities -- it's often one of the most clarifying > and > > > delightful exercises I undertake. Alas, neither of the Erlang books has > any > > > such an appendix (mandatory for a programming language primer, I would > have > > > thought.) For me, that has made learning Erlang harder. > > > > > > "- it's not faster (compile time, might even make compiling slower)" > > > > > > You've got to be kidding. It's long been known: the time complexity of > > > parsing is overwhelmingly dominated by scanning. Code written in the > form I > > > propose would have fewer tokens to scan. > > > > > > "- it doesn't make the parser code easier to maintain" > > > > > > It might, actually. See above. > > > > > > "- it's making a lot of documentation obsolete that will need to be > > > updated. This is common to all changes though." > > > > > > Yes, it is. Not to mention that the documentation on Erlang syntax is > due > > > for an upgrade anyway. The first hit I get on "Erlang" and "fun" yields > the > > > section "Syntax of funs", here: > > > > > > http://www.erlang.org/doc/programming_examples/funs.html#id59209 > > > > > > Yes, believe it: no coverage of the multi-clause case. > > > > > > "You'll be creating a hell of a lot more work ...." > > > > > > Ah, it seems almost obligatory on this thread: exaggeration asserted as > > > fact. Would it really require even as much as a day's work on the > parser? > > > Yes, it would require updating documentation of Erlang syntax, but that > > > documentation that (see above) clearly needs a little work anyway. > > > > > > "Oh and lastly, you could also have to consider this ambiguity ...." > > > > > > It wouldn't even be an ambiguity. It would only be a weird and > pointless > > > way to write that code. And that's IF someone wrote code like that. > Well, > > > anybody can write crappy and confusing code that abuses any language > > > feature. (There it is: my own obligatory exaggeration for this thread.) > Any > > > "obfuscated Erlang contest" would likely to whack the worst Obfuscated > C out > > > the ballpark. (And that's no exaggeration.) > > > > > > -michael turner > > > > > > 2011/5/19 Fr?d?ric Trottier-H?bert > > > > > > Well let's take a look here. Syntax doesn't have to break old code to > > > change, that's a good point. > > > > > > You'll see that if you try {lists, sort}([3,2,1]), you will obtain > [1,2,3]. > > > This basic fun syntax dates from before Erlang actually had funs (fun > > > M:F/A). You'll notice that it was less complex, tends to avoid > verbosity and > > > is somewhat more readable than doing (fun lists:sort/1)([1,2,3]). Going > to > > > the new syntax didn't break any code, didn't require old working code > to be > > > rewritten (things still work the old way, and parametrized modules are > based > > > on that bit of syntax) and people just ignore it if they don't need it. > Yet > > > people did the switch from {Mod, Fun} to fun M:F/A. > > > > > > Why? Because, I figure, people generally liked the new way better: it's > > > faster (apparently much faster), much cleaner in intent and purposes, > and > > > way easier to figure out that we're actually dealing with a higher > order > > > function and not some weird concept. Plus you have to consider that in > many > > > places, you can just use 'Var(Args)' with either form. This switch had > many > > > wins over conciseness. > > > > > > If we try to do the same with your suggestion for the new Erlang > syntax, we > > > can basically see that it has a few advantages: > > > > > > - reduces typing required by avoiding name repetitions > > > - it doesn't break existing code > > > - it somewhat unifies the syntax with funs, but then funs still finish > with > > > 'end' and take no name. > > > > > > > > > I, however, see the following disadvantages: > > > > > > - it creates multiple standards left to personal preference > > > - it makes it less obvious that a function has many clauses (see Steve > > > Davis' code) > > > - it creates more learning overhead if both forms are used. {Mod,Fun} > for > > > funs has no overhead because it's basically deprecated and nobody uses > it. > > > - All the existing tools have to be updated to understand it -- at > least > > > those working on source files (and this includes editors and whatnot) > > > > > > To this, you must add a multiplier damage (heh) for things it doesn't > make > > > better: > > > - it's not faster (compile time, might even make compiling slower) > > > - it doesn't make the parser code easier to maintain > > > - it doesn't make maintaining code in modules easier (except for some > > > readability benefits) > > > - it's not helping people understand the language better (based on my > > > observations that people have no problems with the current form when it > > > comes to understanding) > > > - it's making a lot of documentation obsolete that will need to be > updated. > > > This is common to all changes though. > > > > > > In my opinion, typing less code, even if it doesn't break > compatibility, is > > > not worth the change. You'll be creating a hell of a lot more work if > only > > > to get a bit more concise and consistent syntax on a thing where people > > > don't even agree you get better readability. > > > > > > > > > Oh and lastly, you could also have to consider this ambiguity -- is the > > > following bit of code acceptable? > > > > > > my_function > > > (a,b,c) -> {a,b,c}; > > > (a,c,b) -> {a,b,v}; > > > my_function > > > (c,b,a) -> {a,b,c}. > > > > > > > > > On 2011-05-19, at 09:43 AM, Michael Turner wrote: > > > > > > > "Erlang is sufficiently mature that the syntax is now very difficult > to > > > change." > > > > > > > > Nobody has yet told me why this proposed change would break any > existing > > > code, or why it would require any significant work on the parser. > > > > > > > > > -- > > > Fred H?bert > > > http://www.erlang-solutions.com > > > > > > > > > _______________________________________________ > > > erlang-questions mailing list > > > erlang-questions@REDACTED > > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > -- > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebegumisa@REDACTED Fri May 20 20:17:16 2011 From: ebegumisa@REDACTED (Edmond Begumisa) Date: Sat, 21 May 2011 04:17:16 +1000 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: <661C1ED1-0683-435C-8BF0-5EAB2289D546@erlang-solutions.com> <3E70F4ECA6ED459C936583EE3B7301EC@srstrong.com> Message-ID: Not only did I read your original post I even quoted it. Explaining exactly why _I_ thought it was less readable for Erlang new-comers, hence the only advantage left being writeability. Or do *you* pick and chose what you read? - Edmond - On Sat, 21 May 2011 03:51:22 +1000, Michael Turner wrote: > "But you'll happily imply that others should effect the change " > > Oh, no, I have given up on that. I can now see why it's not going to > happen. > > "... when _they_ tell you that they don't see the need for it, and give > you > _their_ reasons for not wanting to effect it -- you say hogwash! All on a > change that's not that important to you!" > > For some strange reason, it IS important to me when people misrepresent > my > positions. As you just did. > > From the very first post I made on this thread, I talked about > readability. > You responded as if I had prioritized writeability over readability. Is > that > fair? Have you even *read* the first post I made on this? (Which pretty > much > laid out my entire case.)Or do you consider that a dispensable step in > coming to a judgment of my position? > > Here's the core paragraph from that first post: > > "It's also less to type and to read, which is consistent with the DRY > principle ("Don't Repeat Yourself"). And it lends itself to reading a > function definition as a set of cases. I think for Erlang newbies, it > should > therefore would be preferred: it helps underscore the pattern-matching > style > of Erlang function invocation." > > That's an argument in which readability weighs slightly more, isn't it? > > -michael turner > > > On Sat, May 21, 2011 at 2:16 AM, Edmond Begumisa < > ebegumisa@REDACTED> wrote: > >> On Fri, 20 May 2011 23:57:32 +1000, Michael Turner < >> michael.eugene.turner@REDACTED> wrote: >> >> "... looking at both backward *and* forward compatibility issues (what >>> sort >>> >>> of things might this change prevent us from doing in the future?)" >>> >>> I have repeatedly asked people here what this change would break, and >>> in >>> particular how it might compromise backward compatibility. Nobody has >>> answered, so far. Since the change amounts to the compiler silently >>> inserting a function name during parsing at points where some IDE >>> environments already already insert the name literally when you type >>> ";", >>> it's pretty hard to see how there could be a backward compatibility >>> issue. >>> >>> As for forward compatibility, we have it from Joe that syntax changes >>> hardly >>> every happen anyway. So if change is very unlikely to happen, forward >>> compatiblity isn't much of an issue either, is it? >>> >>> As for how many meetings it would take Ericsson to establish that the >>> risk >>> is low/zero, well, OK, got me: I've worked as a software engineer in a >>> couple of large companies, so I know that these things can take time. >>> In >>> fact, I remember life at one networking company where any single >>> engineering >>> change order to the production system required no fewer than 25 >>> signatures. >>> So you may have a point there. (Although I thought part of the point of >>> open >>> source was to circumvent that kind of bureaucratic tarpit. Guess I was >>> wrong.) >>> >> >> One of the main motivations for a private company to open-source their >> proprietary code is to have *others* improve it not just have others >> make >> *suggestions* for its improvement. Suggestions can be obtained even with >> closed source software. >> >> Erlang has the EEP system for this. As others have suggested, if you >> really >> feel strongly on this prove everyone wrong! Write up an EEP. Show >> everyone >> that their fears are exaggerated. Supply a patch so we can see for >> ourselves >> how cool it would be! It wouldn't be the first time a skeptical >> community >> has been eventually convinced. >> >> But there's a problem with this... >> >> >> "Emacs for one would need work since it's syntax highlighting would >> now be >>> broken." >>> >>> It would only be broken for any code that took advantage of the change >>> I >>> suggest. Which would start out at exactly zero percent of the Erlang >>> code >>> out there. As the supposed "harm" grew, well, somebody would go and >>> modify >>> whatever needed to be modified, to make syntax highlighting work as it >>> does >>> in Emacs already for the analogous syntax in Clojure. >>> >>> "If this is so important to you ...." >>> >>> It is not that important to me (at the moment.) >>> >> >> ... it's not that important to you. You have better things to do >> correct? >> At the moment it's just a minor inconvenience, right? So why let it get >> to >> you? >> >> >> However, like anybody else, >>> I hate having my case for change twisted by others, and I hate >>> objections >>> to >>> ideas (mine and others) when the objections don't actually hold water. >>> >> >> So let me understand this... >> >> The change is not _that_ important to you (not important enough to >> effect >> it yourself.) But you'll happily imply that others should effect the >> change >> (which is fair enough BTW -- others may be far more intimate with the >> code >> that would need changing.) But when those others (those both more >> intimate >> with the code and whom you are essentially asking to make the change), >> when >> _they_ tell you that they don't see the need for it, and give you >> _their_ >> reasons for not wanting to effect it -- you say hogwash! All on a change >> that's not that important to you! >> >> That position is a little unfair don't you think? >> >> - Edmond - >> >> >> >> >> If you think the thread is a waste of *your* time, you're free to not >>> contribute to it. >>> >>> -michael turner >>> >>> On Fri, May 20, 2011 at 4:12 PM, Steve Strong >>> wrote: >>> >>> Do you seriously think that a compiler team of a well-established and >>>> widely used language would implement a new syntax in less than a day? >>>> The >>>> code change itself may be relatively trivial (or a total pain in the >>>> arse, >>>> I've not looked at the current compiler code and could believe >>>> either), >>>> but >>>> whichever it is, it will be dwarfed by the design meetings held prior >>>> to >>>> making the change - looking at both backward *and* forward >>>> compatibility >>>> issues (what sort of things might this change prevent us from doing in >>>> the >>>> future?), plus the testing that would need to be performed after. >>>> >>>> And then there's all the tools that would be broken. Emacs for one >>>> would >>>> need work since it's syntax highlighting would now be broken. All >>>> this >>>> for >>>> a really minor change that, judging from the responses on this list, >>>> not >>>> that many people even want. >>>> >>>> Dude, this thread has gone on long enough and wasted way too much >>>> time. >>>> If >>>> this is so important to you, then do it yourself (after all, it's less >>>> than >>>> a days work) and publish the changes. >>>> >>>> Cheers, >>>> >>>> Steve >>>> >>>> -- >>>> Steve Strong, Director, id3as >>>> twitter.com/srstrong >>>> >>>> On Friday, 20 May 2011 at 07:29, Michael Turner wrote: >>>> >>>> Thank you, Fr?d?ric, for taking a serious look at the idea. However, I >>>> see >>>> a few of the same unsubstantiated objections raised, with a couple >>>> more >>>> questionable ones added. >>>> >>>> "- It makes it less obvious that a function has many clauses (see >>>> Steve >>>> Davis' code)" >>>> >>>> WITH Steve's style of indentation. I suggested a more readable >>>> alternative, >>>> where the "(Args)->" part has indentation column to themselves. >>>> (Curiously, >>>> you employ my suggested indentation style yourself, below, in a >>>> supposedly >>>> "ambiguous" code sample.) >>>> >>>> "- it somewhat unifies the syntax with funs, but then funs still >>>> finish >>>> with 'end' and take no name." >>>> >>>> Perhaps syntax would become even more regular than you suggest. What I >>>> propose results in a grammar more like this: >>>> >>>> function: >>>> clause-list + "." >>>> fun: >>>> "fun" + clause-list + "end" >>>> clause: >>>> [optional name] (arg-list) guards -> stmt-list >>>> >>>> This is, if anything, more regular than the grammar is now. Yes, it >>>> *syntactically* allows for a *different* "optional name", but so does >>>> the >>>> current grammar; finding head mismatches *already* requires a separate >>>> step. >>>> And I question whether it requires the parser to produce a different >>>> AST >>>> than we get now, for parse-transform purposes. >>>> >>>> The above syntax also permits naming in funs. Is that so bad? As ROK >>>> has >>>> suggested, pehaps funs ought to be allowed (limited-scope) names to >>>> facilitate recursive definition. I happen to think it would work just >>>> as >>>> well to re-use the keyword "fun" to refer to the fun in the process of >>>> being >>>> defined. But there's something to be said for self-documenting >>>> recursive >>>> funs, so I could go either way on that one. Or both ways. (I hear the >>>> moans: >>>> "Not *another* way to do the same thing..." -- as if they were >>>> actually >>>> the >>>> same. And as if I weren't proposing here to do things ONE way.) >>>> >>>> "- it creates more learning overhead if both forms are used." >>>> >>>> That depends on how you learn (and teach) a language. Really: how much >>>> more >>>> page space does it require to show a slightly different way to do >>>> something? >>>> And then there are different learner styles. After learning the >>>> basics of >>>> a >>>> language, I tend to flip to an appendix like "syntax summary" (in BNF >>>> and >>>> other semi-formal styles), to start exploring the meaning of different >>>> combinatorial possibilities -- it's often one of the most clarifying >>>> and >>>> delightful exercises I undertake. Alas, neither of the Erlang books >>>> has >>>> any >>>> such an appendix (mandatory for a programming language primer, I would >>>> have >>>> thought.) For me, that has made learning Erlang harder. >>>> >>>> "- it's not faster (compile time, might even make compiling slower)" >>>> >>>> You've got to be kidding. It's long been known: the time complexity of >>>> parsing is overwhelmingly dominated by scanning. Code written in the >>>> form >>>> I >>>> propose would have fewer tokens to scan. >>>> >>>> "- it doesn't make the parser code easier to maintain" >>>> >>>> It might, actually. See above. >>>> >>>> "- it's making a lot of documentation obsolete that will need to be >>>> updated. This is common to all changes though." >>>> >>>> Yes, it is. Not to mention that the documentation on Erlang syntax is >>>> due >>>> for an upgrade anyway. The first hit I get on "Erlang" and "fun" >>>> yields >>>> the >>>> section "Syntax of funs", here: >>>> >>>> http://www.erlang.org/doc/programming_examples/funs.html#id59209 >>>> >>>> Yes, believe it: no coverage of the multi-clause case. >>>> >>>> "You'll be creating a hell of a lot more work ...." >>>> >>>> Ah, it seems almost obligatory on this thread: exaggeration asserted >>>> as >>>> fact. Would it really require even as much as a day's work on the >>>> parser? >>>> Yes, it would require updating documentation of Erlang syntax, but >>>> that >>>> documentation that (see above) clearly needs a little work anyway. >>>> >>>> "Oh and lastly, you could also have to consider this ambiguity ...." >>>> >>>> It wouldn't even be an ambiguity. It would only be a weird and >>>> pointless >>>> way to write that code. And that's IF someone wrote code like that. >>>> Well, >>>> anybody can write crappy and confusing code that abuses any language >>>> feature. (There it is: my own obligatory exaggeration for this >>>> thread.) >>>> Any >>>> "obfuscated Erlang contest" would likely to whack the worst >>>> Obfuscated C >>>> out >>>> the ballpark. (And that's no exaggeration.) >>>> >>>> -michael turner >>>> >>>> 2011/5/19 Fr?d?ric Trottier-H?bert >>>> >>>> Well let's take a look here. Syntax doesn't have to break old code to >>>> change, that's a good point. >>>> >>>> You'll see that if you try {lists, sort}([3,2,1]), you will obtain >>>> [1,2,3]. >>>> This basic fun syntax dates from before Erlang actually had funs (fun >>>> M:F/A). You'll notice that it was less complex, tends to avoid >>>> verbosity >>>> and >>>> is somewhat more readable than doing (fun lists:sort/1)([1,2,3]). >>>> Going >>>> to >>>> the new syntax didn't break any code, didn't require old working code >>>> to >>>> be >>>> rewritten (things still work the old way, and parametrized modules are >>>> based >>>> on that bit of syntax) and people just ignore it if they don't need >>>> it. >>>> Yet >>>> people did the switch from {Mod, Fun} to fun M:F/A. >>>> >>>> Why? Because, I figure, people generally liked the new way better: >>>> it's >>>> faster (apparently much faster), much cleaner in intent and purposes, >>>> and >>>> way easier to figure out that we're actually dealing with a higher >>>> order >>>> function and not some weird concept. Plus you have to consider that in >>>> many >>>> places, you can just use 'Var(Args)' with either form. This switch had >>>> many >>>> wins over conciseness. >>>> >>>> If we try to do the same with your suggestion for the new Erlang >>>> syntax, >>>> we >>>> can basically see that it has a few advantages: >>>> >>>> - reduces typing required by avoiding name repetitions >>>> - it doesn't break existing code >>>> - it somewhat unifies the syntax with funs, but then funs still finish >>>> with >>>> 'end' and take no name. >>>> >>>> >>>> I, however, see the following disadvantages: >>>> >>>> - it creates multiple standards left to personal preference >>>> - it makes it less obvious that a function has many clauses (see Steve >>>> Davis' code) >>>> - it creates more learning overhead if both forms are used. {Mod,Fun} >>>> for >>>> funs has no overhead because it's basically deprecated and nobody uses >>>> it. >>>> - All the existing tools have to be updated to understand it -- at >>>> least >>>> those working on source files (and this includes editors and whatnot) >>>> >>>> To this, you must add a multiplier damage (heh) for things it doesn't >>>> make >>>> better: >>>> - it's not faster (compile time, might even make compiling slower) >>>> - it doesn't make the parser code easier to maintain >>>> - it doesn't make maintaining code in modules easier (except for some >>>> readability benefits) >>>> - it's not helping people understand the language better (based on my >>>> observations that people have no problems with the current form when >>>> it >>>> comes to understanding) >>>> - it's making a lot of documentation obsolete that will need to be >>>> updated. >>>> This is common to all changes though. >>>> >>>> In my opinion, typing less code, even if it doesn't break >>>> compatibility, >>>> is >>>> not worth the change. You'll be creating a hell of a lot more work if >>>> only >>>> to get a bit more concise and consistent syntax on a thing where >>>> people >>>> don't even agree you get better readability. >>>> >>>> >>>> Oh and lastly, you could also have to consider this ambiguity -- is >>>> the >>>> following bit of code acceptable? >>>> >>>> my_function >>>> (a,b,c) -> {a,b,c}; >>>> (a,c,b) -> {a,b,v}; >>>> my_function >>>> (c,b,a) -> {a,b,c}. >>>> >>>> >>>> On 2011-05-19, at 09:43 AM, Michael Turner wrote: >>>> >>>> > "Erlang is sufficiently mature that the syntax is now very >>>> difficult to >>>> change." >>>> > >>>> > Nobody has yet told me why this proposed change would break any >>>> existing >>>> code, or why it would require any significant work on the parser. >>>> >>>> >>>> -- >>>> Fred H?bert >>>> http://www.erlang-solutions.com >>>> >>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>>> >>>> >>>> >> >> -- >> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ >> -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From jesper.louis.andersen@REDACTED Fri May 20 20:56:15 2011 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Fri, 20 May 2011 20:56:15 +0200 Subject: [erlang-questions] What are the "Most valuable libraries?"...and a few other questions In-Reply-To: <4DD311FF.2090402@gmail.com> References: <20110517142848.GA9263@erix.ericsson.se> <230D6DBF-EE90-475F-A973-DF0E7B71EF19@cs.otago.ac.nz> <4DD311FF.2090402@gmail.com> Message-ID: On Wed, May 18, 2011 at 02:25, Todd wrote: Let me be quite blunt here... > 1. In general, what are the most valuable libraries to learn, both within > the Erlang dist and external? > > 2. Is there a consolidated/curated repository of libraries that is industry > standard? I know the erlware folks have a repo...is that both a complete and > accepted authoritative repo? From reading the list, it sounds like there's > also a fair bit of stuff scattered about in github, too. I think this approach to Erlang is wrong. Rather than ask for a set of "standard" modules to look into you should attack it on a on-demand basis when you find a need for a specific library. Personally, I really like the Agner system which aims to be a system listing available software so you can use it. It intermingles with the Rebar build system in a neat way. Erlang seeks to provide tools, not solutions. As such, you will find a lot of tools in the OTP distribution and elsewhere which will give you stuff to write your own solutions. But you won't find any prebaked solutions which magically solves the problem you are looking at. > 3. How does one easily multithread an app? For instance, there's pmap in > clojure and something similar in akka that lets you map a function across a > list, and it allocates threads accordingly... There is no easy way to multi-thread an app so it gives good speedup when adding more cores. There are some general guidelines you can follow when writing the program, but they do not always yield a speedup. Here is a simple module: -module(foo). -compile(export_all). m(X) -> X*2. test_input() -> lists:seq(1, 10000). t1(L) -> timer:tc(fun() -> [m(X) || X <- L] end). t2(L) -> timer:tc(rpc, pmap, [{foo, m}, [], L]). where t1/1 and t2/1 are our tests. t1 uses a list comprehension and t2 uses the pmap function of the rpc module to execute in parallel on my two cores. A simple experiment in the shell: Eshell V5.8.4 (abort with ^G) 1> c(foo). {ok,foo} 2> L = test_input(). ** exception error: undefined shell command test_input/0 3> L = foo:test_input(). [1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22, 23,24,25,26,27,28,29|...] 4> X = foo:t1(L). {2491, [2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40,42, 44,46,48,50,52,54|...]} 5> Y = foo:t2(L). {65111, [2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40,42, 44,46,48,50,52,54|...]} 6> shows how t1 is much much faster than t2. You need to know a lot about the problem at hand to make it faster. If your m/1 function is altered to this: m(X) -> timer:sleep(3), X*2. so we in the parallel example can do other work in between, then the numbers are different: 3> X1 = foo:t1(L). {40112834, [2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40,42, 44,46,48,50,52,54|...]} 4> X2 = foo:t2(L). {105134, [2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40,42, 44,46,48,50,52,54|...]} in much in favor of t2. Hopefully this shows you need to know about your problem to make it go faster. There is no magical solution. It is also important to note that in Erlang, concurrency was added to build fault tolerant programs. Not to make programs run faster. It is neat that it is often the case that it helps on multi-core machines, but it was not the initial goal. > 4. Along that note, does anyone have any ideas as to how to tackle the > Typesafe 'getting started tutorial?' > > http://typesafe.com/resources/getting-started/tutorials/getting-started-first-scala.html Yikes! All that code in Erlang is: calc_pi_worker({Start, N}) -> lists:sum( [4.0 * (1 - (I rem 2) * 2) / (2 * I + 1) || I <- lists:seq(Start, Start+N-1)]). calc_pi() -> K = 10000, lists:sum([calc_pi_worker({I*K, K}) || I <- lists:seq(0,K-1)]). if we run it sequentially it gives the correct result, but is fairly slow since we generate a lot of data that subsequently becomes garbage. calc_pi_worker/1 can be optimized by moving stuff out of the main loop and not building the list with lists:seq/2 each time around. calc_pi/0 can be optimized by using the plists library (https://github.com/eveel/plists). So while we are at it, let us parallelize. And let us not create all that boiler plate while doing it! Here is the code: -module(foo). -compile(export_all). calc_pi_worker({Start, N}) -> calc_pi_worker(Start, N, 0). calc_pi_worker(_I, 0, Acc) -> Acc; calc_pi_worker(I, K, Acc) -> S = (1 - (I rem 2) * 2) / (2 * I + 1), calc_pi_worker(I+1, K-1, Acc + S). calc_pi() -> K = 10000, 4.0 * lists:sum(plists:map(fun foo:calc_pi_worker/1, [{I*K, K} || I <- lists:seq(0, K-1)])). Yes, we don't have to change anything else. This is parallel using as many cores as you have. It can be tuned some more, but for a start it is magnificent, even though it is slower than the Akka-version. > 4b. Side note: is anyone concerned about Akka/Typesafe stealing mindshare? Well, if you want to write all the boiler plate code they have to write, then go ahead. I'd rather not :) Seriously though, the mindshare we will steal are from Non-concurrent languages, be it Python, Ruby, Java, C# or ... -- We are in the same boat as Scala/Akka, Go and so on. The influx of interested programmers will be large, so we don't have to worry too much about who steals from whom. Erlang has the distinct advantage of being old, tried, battle-hardened and extremely robust. It has a main focus on fault tolerance, which gives it some unique capabilities. Also, its focus on using functional programming is a robustness advantage. You can't just copy part of Erlang to obtain what it provides. You have to have all of it and then some. > 5. How does one push an app such that it self instantiates it's processes > across the cluster? I can see how OTP is great at managing an app on a > single node, but how do you say something like: "create one of these > processes on each node in the cluster, and restart 1-for-1 if they die"... > or something similar. I see mention of gproc, but honestly, I don't see how > to use it. Likewise, if nodes are added to the cluster, how would you ensure > that the necessary processes are pushed to the new node after it joins the > cluster? Essentially this is handled by the application if it is written to adhere to some rules of Erlang and if you write application such that it does not assume all of it is present locally on a single VM, but is distributed across multiple. There is no automatic solution here either. For each application you will need to define what to do. For some applications a 'takeover' is enough. There is one running and if the node it runs on crashes, then another node will take over the job and arrange that requests are now redirected to the new node. For other systems, like Riak, all nodes are simultaneously runing and the application on each node talks to the same application on other nodes to internally manage state. Yes, it is a hard problem. But Erlang provides you with the tools to solve it. > 6. How do you deploy and live code upgrade in real life? I've been looking > at some of the work by the 'Dukes of Erl' ... is erlrc what folks commononly > use? I don't. The projects I am working on has the virtue that we can do rolling upgrades by closing down machines and restart them. You will have to ask someone else :) > 7. Does anyone use dynamic load balancing of demand across a cluster (e.g. > spinning up erlang processes to meet the demand curve?) I am sure there are people who does this. But I'll let them answer the question. It is not that hard to pull off. > 8. What's the best way to integrate w/ other code bases. In akka, you'd use > camel as an integration bus. What are the common ways to integrate with > erlang? Is that what ports and nifs are for? Forgive my ignorance, but I > always considered those as simply ways to write code in a different, perhaps > more comfortable language...not as integration mechanisms. Integration is perhaps Erlangs strength. NIFs are for writing small hotspots in your code in C for speed. The calc_pi_worker/1 from above comes to mind for instance. Ports are used for several things. They are a representation in the Erlang VM of something external. It can be another process, where we have a pipe for communication. It can be a file on disk. It can be a network socket. Or it can be a linked in driver. Another option is to make a node in another language that talks the Erlang distribution protocol. Yet another option is to use a message queue like ZeroMQ or AQMP for communication. Finally, you can do like my own project and simply implement the foreign protocol in Erlang - BitTorrent in my case. Erlang rocks for implementing foreign protocols. > Also, I've continued to peck away at various newbie tutorials. Any > comments/suggestions/corrections are welcome. You never go wrong with Fred Herbert: http://learnyousomeerlang.com/ - witty, informative, awesome -- even if the octopus has too few tentacles. -- J. From pablo.platt@REDACTED Sat May 21 02:09:59 2011 From: pablo.platt@REDACTED (Pablo Platt) Date: Fri, 20 May 2011 17:09:59 -0700 (PDT) Subject: [erlang-questions] missing error reports from erlang.log.1 Message-ID: <367806.9716.qm@web112603.mail.gq1.yahoo.com> I've created a release with rebar. I'm starting the app with myapp/rel/myapp/bin/myapp start Error reports are not being written to rel/myapp/log/error.log.1 although the file is created and the initialization text is written to it (LOGGING STARTED Sat May...). If I'm writing one line with the error_logger in myapp_sup:init/1, compile and run the app, I do see error reports in the error.log.1 file. The line is: error_logger:error_msg("dummy error report~n") Am I missing initialization of an app related to error logging or do I need to change some configurations? Does the error_logger:error_msg fix it by forcing initialization of this app? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From t.greenwoodgeer@REDACTED Sat May 21 07:44:33 2011 From: t.greenwoodgeer@REDACTED (Todd Greenwood) Date: Fri, 20 May 2011 22:44:33 -0700 Subject: [erlang-questions] What are the "Most valuable libraries?"...and a few other questions In-Reply-To: References: <20110517142848.GA9263@erix.ericsson.se> <230D6DBF-EE90-475F-A973-DF0E7B71EF19@cs.otago.ac.nz> <4DD311FF.2090402@gmail.com> Message-ID: <4DD75141.8060708@gmail.com> Jesper, thanks for the response. I've been a bit remiss in thanking folks for their responses to my lengthy questions...I'm a bit pressed for time as I'm packing in preparation for moving. More inline: On 5/20/11 11:56 AM, Jesper Louis Andersen wrote: > On Wed, May 18, 2011 at 02:25, Todd wrote: > > Let me be quite blunt here... > >> 1. In general, what are the most valuable libraries to learn, both within >> the Erlang dist and external? >> >> 2. Is there a consolidated/curated repository of libraries that is industry >> standard? I know the erlware folks have a repo...is that both a complete and >> accepted authoritative repo? From reading the list, it sounds like there's >> also a fair bit of stuff scattered about in github, too. > > I think this approach to Erlang is wrong. Rather than ask for a set of > "standard" modules to look into you should attack it on a on-demand > basis when you find a need for a specific library. Personally, I > really like the Agner system which aims to be a system listing > available software so you can use it. It intermingles with the Rebar > build system in a neat way. Thanks for mentioning Agner, that looks cool. I'll noodle around and figure out how it links with rebar. For those of you that have been programming in erlang for some time, it would be useful for those of us, newer to erlang, to understand what libraries are your bread-and-butter, as opposed to domain specific libraries. As an example, if someone were to ask me this about Java, I'd suggest...understand threading semantics, java.util.collections, immutable collections (guava), IOC...and JUnit. The rest would be specific to the problem domain (e.g. Spring Framework, hibernate|JDBC, EJB3, and other more specific libraries. ) > > Erlang seeks to provide tools, not solutions. As such, you will find a > lot of tools in the OTP distribution and elsewhere which will give you > stuff to write your own solutions. But you won't find any prebaked > solutions which magically solves the problem you are looking at. > >> 3. How does one easily multithread an app? For instance, there's pmap in >> clojure and something similar in akka that lets you map a function across a >> list, and it allocates threads accordingly... > > There is no easy way to multi-thread an app so it gives good speedup > when adding more cores. There are some general guidelines you can > follow when writing the program, but they do not always yield a > speedup. Here is a simple module: > > -module(foo). > -compile(export_all). > > m(X) -> > X*2. > > test_input() -> > lists:seq(1, 10000). > > t1(L) -> > timer:tc(fun() -> > [m(X) || X<- L] > end). > > t2(L) -> > timer:tc(rpc, pmap, [{foo, m}, [], L]). > > where t1/1 and t2/1 are our tests. t1 uses a list comprehension and t2 > uses the pmap function of the rpc module to execute in parallel on my > two cores. A simple experiment in the shell: > > Eshell V5.8.4 (abort with ^G) > 1> c(foo). > {ok,foo} > 2> L = test_input(). > ** exception error: undefined shell command test_input/0 > 3> L = foo:test_input(). > [1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22, > 23,24,25,26,27,28,29|...] > 4> X = foo:t1(L). > {2491, > [2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40,42, > 44,46,48,50,52,54|...]} > 5> Y = foo:t2(L). > {65111, > [2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40,42, > 44,46,48,50,52,54|...]} > 6> > > shows how t1 is much much faster than t2. You need to know a lot about > the problem at hand to make it faster. If your m/1 function is altered > to this: > > m(X) -> > timer:sleep(3), > X*2. > > so we in the parallel example can do other work in between, then the > numbers are different: > > 3> X1 = foo:t1(L). > {40112834, > [2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40,42, > 44,46,48,50,52,54|...]} > 4> X2 = foo:t2(L). > {105134, > [2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40,42, > 44,46,48,50,52,54|...]} > > in much in favor of t2. Hopefully this shows you need to know about > your problem to make it go faster. There is no magical solution. > I'm pretty familiar with this sort of thing in other languages, but it's nice to see such a clear example. For me, the missing piece was the rpc module that contains the pmap function. I'll have to look closely at that module. > It is also important to note that in Erlang, concurrency was added to > build fault tolerant programs. Not to make programs run faster. It is > neat that it is often the case that it helps on multi-core machines, > but it was not the initial goal. > >> 4. Along that note, does anyone have any ideas as to how to tackle the >> Typesafe 'getting started tutorial?' >> >> http://typesafe.com/resources/getting-started/tutorials/getting-started-first-scala.html > > Yikes! All that code in Erlang is: > > calc_pi_worker({Start, N}) -> > lists:sum( > [4.0 * (1 - (I rem 2) * 2) / (2 * I + 1) || > I<- lists:seq(Start, Start+N-1)]). > > calc_pi() -> > K = 10000, > lists:sum([calc_pi_worker({I*K, K}) || I<- lists:seq(0,K-1)]). > > if we run it sequentially it gives the correct result, but is fairly > slow since we generate a lot of data that subsequently becomes > garbage. calc_pi_worker/1 can be optimized by moving stuff out of the > main loop and not building the list with lists:seq/2 each time around. > calc_pi/0 can be optimized by using the plists library > (https://github.com/eveel/plists). So while we are at it, let us > parallelize. And let us not create all that boiler plate while doing > it! Here is the code: > > -module(foo). > -compile(export_all). > > calc_pi_worker({Start, N}) -> > calc_pi_worker(Start, N, 0). > > calc_pi_worker(_I, 0, Acc) -> Acc; > calc_pi_worker(I, K, Acc) -> > S = (1 - (I rem 2) * 2) / (2 * I + 1), > calc_pi_worker(I+1, K-1, Acc + S). > > calc_pi() -> > K = 10000, > 4.0 * lists:sum(plists:map(fun foo:calc_pi_worker/1, > [{I*K, K} || I<- lists:seq(0, K-1)])). > > Yes, we don't have to change anything else. This is parallel using as > many cores as you have. It can be tuned some more, but for a start it > is magnificent, even though it is slower than the Akka-version. > Wow. That's impressive. I'll take a closer look at the plists module, too. In a way, that's what I was talking about earlier in this email w/ respect to bread-and-butter libs. You pulled plists out of your back pocket...what else have you got there? >> 4b. Side note: is anyone concerned about Akka/Typesafe stealing mindshare? > > Well, if you want to write all the boiler plate code they have to > write, then go ahead. I'd rather not :) > > Seriously though, the mindshare we will steal are from Non-concurrent > languages, be it Python, Ruby, Java, C# or ... -- We are in the same > boat as Scala/Akka, Go and so on. The influx of interested programmers > will be large, so we don't have to worry too much about who steals > from whom. Erlang has the distinct advantage of being old, tried, > battle-hardened and extremely robust. It has a main focus on fault > tolerance, which gives it some unique capabilities. Also, its focus on > using functional programming is a robustness advantage. You can't just > copy part of Erlang to obtain what it provides. You have to have all > of it and then some. > >> 5. How does one push an app such that it self instantiates it's processes >> across the cluster? I can see how OTP is great at managing an app on a >> single node, but how do you say something like: "create one of these >> processes on each node in the cluster, and restart 1-for-1 if they die"... >> or something similar. I see mention of gproc, but honestly, I don't see how >> to use it. Likewise, if nodes are added to the cluster, how would you ensure >> that the necessary processes are pushed to the new node after it joins the >> cluster? > > Essentially this is handled by the application if it is written to > adhere to some rules of Erlang and if you write application such that > it does not assume all of it is present locally on a single VM, but is > distributed across multiple. There is no automatic solution here > either. For each application you will need to define what to do. For > some applications a 'takeover' is enough. There is one running and if > the node it runs on crashes, then another node will take over the job > and arrange that requests are now redirected to the new node. For > other systems, like Riak, all nodes are simultaneously runing and the > application on each node talks to the same application on other nodes > to internally manage state. > > Yes, it is a hard problem. But Erlang provides you with the tools to solve it. > I have to admit, this is something that really intrigues me... creating an app that can move around in a cluster as nodes go up or down...as well as responding to load and spinning up new processes on nodes to handle the load. One thought I've had is to use erlang to manage os processes to spin up new erlang nodes on remote machines. Or to have erlang spin up an external resource, like a database or message queue and link to it. >> 6. How do you deploy and live code upgrade in real life? I've been looking >> at some of the work by the 'Dukes of Erl' ... is erlrc what folks commononly >> use? > > I don't. The projects I am working on has the virtue that we can do > rolling upgrades by closing down machines and restart them. You will > have to ask someone else :) How do you insure that, as you roll a cluster from v1 to v2, the new v2 nodes don't corrupt the data that v1 is using? On all the large projects I've been involved with (java,jdbc,mysql,etc.), there are typically service level changes that are tightly coupled to sql ddl changes... thereby requiring downing the entire cluster, applying the ddl deltas to the dbs, and subsequently restarting the service instances. So, what is it about your strategy that allows you to do rolling upgrades? > >> 7. Does anyone use dynamic load balancing of demand across a cluster (e.g. >> spinning up erlang processes to meet the demand curve?) > > I am sure there are people who does this. But I'll let them answer the > question. It is not that hard to pull off. > >> 8. What's the best way to integrate w/ other code bases. In akka, you'd use >> camel as an integration bus. What are the common ways to integrate with >> erlang? Is that what ports and nifs are for? Forgive my ignorance, but I >> always considered those as simply ways to write code in a different, perhaps >> more comfortable language...not as integration mechanisms. > > Integration is perhaps Erlangs strength. NIFs are for writing small > hotspots in your code in C for speed. The calc_pi_worker/1 from above > comes to mind for instance. Ports are used for several things. They > are a representation in the Erlang VM of something external. It can be > another process, where we have a pipe for communication. > It can be a file on disk. Is inotify the standard way to monitor file changes on disk from erlang? http://www.trapexit.org/forum/viewtopic.php?p=44414 It can be a network socket. Or it can be a linked in > driver. Another option is to make a node in another language that > talks the Erlang distribution protocol. Yet another option is to use a > message queue like ZeroMQ or AQMP for communication. ZeroMQ is definitely interesting, provided you can accept message losses. Finally, you can > do like my own project and simply implement the foreign protocol in > Erlang - BitTorrent in my case. Erlang rocks for implementing foreign > protocols. > Ah, that's a great idea. I really hadn't thought of integrating at the protocol layer. >> Also, I've continued to peck away at various newbie tutorials. Any >> comments/suggestions/corrections are welcome. > > You never go wrong with Fred Herbert: > > http://learnyousomeerlang.com/ - witty, informative, awesome -- even > if the octopus has too few tentacles. > > Yeah, that's a great site. I've also read all three books, several times actually. For me, erlang has been quite a different learning curve from other languages. Thanks for your detailed responses. This has been really informative, especially the calc_pi() example. -Todd From pablo.platt@REDACTED Sat May 21 10:50:11 2011 From: pablo.platt@REDACTED (Pablo Platt) Date: Sat, 21 May 2011 01:50:11 -0700 (PDT) Subject: [erlang-questions] missing error reports from erlang.log.1 In-Reply-To: <367806.9716.qm@web112603.mail.gq1.yahoo.com> References: <367806.9716.qm@web112603.mail.gq1.yahoo.com> Message-ID: <712042.7852.qm@web112604.mail.gq1.yahoo.com> The errors I'm expecting to see in my test are {error,emfile} because of too many http connections. My guess is that the error_logger need a file descriptor to write to the log file. If I'm writing an error message with the error_logger before the test, the error_logger already has a file descriptor and can use it. If I start the test before using the error_logger, when it tries to get a file descriptor and write to the log, there are no file descriptors left. Shouldn't the error_logger get the file descriptor when starting the app automatically and be immune to this kind of problem? Maybe there is still some config options/app missing in my release? ________________________________ From: Pablo Platt To: "erlang-questions@REDACTED" Sent: Saturday, May 21, 2011 3:09 AM Subject: [erlang-questions] missing error reports from erlang.log.1 I've created a release with rebar. I'm starting the app with myapp/rel/myapp/bin/myapp start Error reports are not being written to rel/myapp/log/error.log.1 although the file is created and the initialization text is written to it (LOGGING STARTED Sat May...). If I'm writing one line with the error_logger in myapp_sup:init/1, compile and run the app, I do see error reports in the error.log.1 file. The line is: error_logger:error_msg("dummy error report~n") Am I missing initialization of an app related to error logging or do I need to change some configurations? Does the error_logger:error_msg fix it by forcing initialization of this app? Thanks _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Sat May 21 14:31:07 2011 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Sat, 21 May 2011 14:31:07 +0200 Subject: [erlang-questions] A Trick for tracking the Erlang dev branch. Message-ID: I often need to track the Erlang dev branch for what I am doing. Hence, I am fairly often rebuilding Erlang/OTP. Also, I am using Ubuntu and the default installation has historically been riddled with odd design decisions. Hence, I am building from source. Unfortunately, this also means you may be the only one running that particular release and that gives problems when reporting bugs. This is trick I use to build Erlang/OTP. 1. Install stow, sudo aptitude install stow If you don't know what stow does, it maintains a symbolic link farm for you in /usr/local so we can enable/disable Erlang versions at whim and have multiple installed Erlangs. It also means cleaning up is easy since each program in /usr/local is installed in its own dir. 2. Execute sudo aptitude build-dep erlang to pull in all build dependencies we need. Since we are on Ubuntu and Ubuntu *does* have an Erlang we can exploit it knows about the dependencies we need. 3. Execute git clone git://github.com/erlang/otp.git to pull the source off of git. 4. Get into the directory and fire away git checkout dev && ./otp_build autoconf which sets up the environment and runs autoconf. 5. Get a useful tag for the otp version you have built otp_version=$(git describe) This is the trick! `git describe` will output to us a useful tag. In my case it is OTP_R14B02-625-g5f7fa62 which means we are 625 commits *after* the R14B02 tag and the SHA1 of that commit start with g5f7fa62. In other words, I now have a neat hook I can report back to the Erlang Devs if there are any problems and we will know exactly on which commit I am and exactly what fixes I may not have present in my build. In some of my projects I have a -tainted I add to the `git describe` if I have local changes not present upstream and then I embed this in the version string of my software. Hence, if some downstream (Ubuntu packagers, etc) choose to patch the software I know it has some patches on it I need to investigate the contents of. 6. ./configure --prefix=/usr/local/stow/${otp_version} Throw the build into the stow directory. 7. make; make docs install install-docs 8 And then I enable it in stow: cd /usr/local/stow && stow ${otp_version} You may have to use stow -D on an old version first to remove the symbolic link farm of that one. -- J. From paul.james.barry@REDACTED Sat May 21 15:00:38 2011 From: paul.james.barry@REDACTED (Paul Barry) Date: Sat, 21 May 2011 14:00:38 +0100 Subject: [erlang-questions] Newbie observation. Message-ID: Hello folks. So my ring of 10,000 processes is processing 10,000 messages (around the ring)... and it's taking a while. So I ask "top" to report on what's happening. I'm seeing 190% CPU usage... and then it hits me. I've a dual core and Erlang is happily using both of them. Right? Paul. P.S. It took just over 5 minutes on my 18 month old Mac Book Pro. :-) -- Paul Barry, w: http://paulbarry.itcarlow.ie, e: paul.barry@REDACTED Lecturer, Computer Networking: Institute of Technology, Carlow, Ireland. From seancribbs@REDACTED Sat May 21 15:50:47 2011 From: seancribbs@REDACTED (Sean Cribbs) Date: Sat, 21 May 2011 09:50:47 -0400 Subject: [erlang-questions] missing error reports from erlang.log.1 In-Reply-To: <712042.7852.qm@web112604.mail.gq1.yahoo.com> References: <367806.9716.qm@web112603.mail.gq1.yahoo.com> <712042.7852.qm@web112604.mail.gq1.yahoo.com> Message-ID: That's not error_logger, but run_erl that's writing to the erlang.log.* files. It is a separate process from the Erlang VM, and so shouldn't be under the same open-files limit as the VM. On Riak installations where the open files limit is too low, we frequently see accept errors from mochiweb or emfile errors, so you're on the right track. Sean Cribbs On Sat, May 21, 2011 at 4:50 AM, Pablo Platt wrote: > The errors I'm expecting to see in my test are {error,emfile} because of too > many http connections. > My guess is that the error_logger need a file descriptor to write to the log > file. > If I'm writing an error message with the error_logger before the test, the > error_logger already has a file descriptor and can use it. > If I start the test before using the error_logger, when it tries to get a > file descriptor and write to the log, there are no file descriptors left. > Shouldn't the error_logger get the file descriptor when starting the app > automatically and be immune to this kind of problem? > Maybe there is still some config options/app missing in my release? > > ________________________________ > From: Pablo Platt > To: "erlang-questions@REDACTED" > Sent: Saturday, May 21, 2011 3:09 AM > Subject: [erlang-questions] missing error reports from erlang.log.1 > > I've created a release with rebar. > I'm starting the app with myapp/rel/myapp/bin/myapp start > Error reports are not being written to rel/myapp/log/error.log.1 although > the file is created and the initialization text is written to it (LOGGING > STARTED Sat May...). > If I'm writing one line with the error_logger in myapp_sup:init/1, compile > and run the app, I do see error reports in the error.log.1 file. > The line is: > error_logger:error_msg("dummy error report~n") > Am I missing initialization of an app related to error logging or do I need > to change some configurations? > Does the error_logger:error_msg fix it by forcing initialization of this > app? > Thanks > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > From sigmastar@REDACTED Sat May 21 15:58:44 2011 From: sigmastar@REDACTED (Jesse Gumm) Date: Sat, 21 May 2011 08:58:44 -0500 Subject: [erlang-questions] Newbie observation. In-Reply-To: Message-ID: <4dd7c51a.545ee70a.385a.ffff8eff@mx.google.com> Sounds like it! I'm not sure if Mac's top is any different (i'd assume not), but if it's not, you can press 1 to get a breakdown of individual CPUs. Alternatively, htop gives a nice graph representation. I'm a total sucker for htop. -Jesse -- Jesse Gumm Sigma Star Systems 414.940.4866 On May 21, 2011 8:00 AM, Paul Barry <paul.james.barry@REDACTED> wrote: Hello folks. So my ring of 10,000 processes is processing 10,000 messages (around the ring)... and it's taking a while. So I ask "top" to report on what's happening. I'm seeing 190% CPU usage... and then it hits me. I've a dual core and Erlang is happily using both of them. Right? Paul. P.S. It took just over 5 minutes on my 18 month old Mac Book Pro. :-) -- Paul Barry, w: http://paulbarry.itcarlow.ie, e: paul.barry@REDACTED Lecturer, Computer Networking: Institute of Technology, Carlow, Ireland. _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From jameschurchman@REDACTED Sat May 21 16:57:28 2011 From: jameschurchman@REDACTED (James Churchman) Date: Sat, 21 May 2011 15:57:28 +0100 Subject: [erlang-questions] AST record syntax improvement Message-ID: Doubt im alone in saying that the record syntax is not only poor, but very acidic to erlang programming. It moves the balance of when you should stop using a tuple and over to a record strongly to the "il keep using a tuple thanks" end of things. There was one attempt ( maybe two ) to fix records but it had a few problems : the good points: 1) the accessor pattern was great, and ever better for accessing records in records. something not easy in the regular syntax!! 2) its better than the normal record syntax! 3) it auto detected records, but just within that one function, by noticing the first time it was used as a record. 4) it added 0 performance penalty for using this new syntax the not so good points :-) : 1) it was very unreliable, totally unrelated to records erlang code would randomly break and your left debugging a parse transform that's very deep, half way threw, all your code. 2) updater code was kinda bad & weird and also made other valid erlang code into something else 3) maybe a small point, but if you are shipping code to clients, they may not like code that ships with dependancies on unsupported parse-transform libraries 4) if you have one record that spans almost all your code in that module, you still have to repeat the fact its a record at least once in every function here is is from all the way back in 2006 http://yarivsblog.blogspot.com/2006/10/recless-type-inferring-parse-transform.html I know there has been some talk of a record replaclemnt in Erl/OTP but i am planing on producing my own in the meantime, from a *simplified* AST parse transform and the syntax would look like this: > Accessing : Value = RecordTypeVariable.element1.sub_element_of_elemet_1 etc.. just like recless ( also without "=" match like do_func(RecordTypeVariable.element1) ) > No multiple access, its not really needed in this case > Updating : NewRec = RecordTypeVariable(element1.sub_element_of_elemet_1="mynewvalue",element2="mynewvalue_for_element2"). This combines the record syntax with the fun syntax, so looks semi-familiar and importantly will not produce a syntax error before the parse transform ( otherwise i could have the updater with {}). The alternate is to mix with record syntax with the (no so popular) PMod syntax like RecordTypeVar:rec_update(element1.elem1_sub_elem=....) if the same record is used throughout, it would be possible, but entirly optional, to set a "global record" for the module, so any var name matching that "global record" would be auto set eg : -global_record(state,['State']). ( single quotes needed to make the capital value an atom ) Producing a revers that generates the original record syntax for shipping to clients would be useful i feel too! So any thoughts on my updater syntax? or suggestions that could be better ( keeping i mind that it still has to pass the first step of parsing!) James -------------- next part -------------- An HTML attachment was scrubbed... URL: From torben.lehoff@REDACTED Sat May 21 16:57:36 2011 From: torben.lehoff@REDACTED (Torben Hoffmann) Date: Sat, 21 May 2011 16:57:36 +0200 Subject: [erlang-questions] how to access process heap from outside the process In-Reply-To: <37069.1305337839@snookles.snookles.com> References: <15485743.41e015f9.4dcb3aa2.ad7f7@o2.pl> <37069.1305337839@snookles.snookles.com> Message-ID: How about http://www.erlang.org/doc/man/sys.html#get_status-1 ? If you are using OTP processes they will spit out most of their guts using this. I have used this in the field and it is info that makes you very informed and that is rarely a bad thing ;-) Cheers, Torben On Sat, May 14, 2011 at 03:50, Scott Lystig Fritchie wrote: > dzejefkej wrote: > > d> hi, I need to sniff state of the process. > > You can't. Well, you can cheat, using erlang:process_info/2. See > http://www.erlang.org/doc/man/erlang.html#process_info-2 for the docs. > Perhaps the 'backtrace' option is closest to what you might be looking > for? > > -Scott > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- http://www.linkedin.com/in/torbenhoffmann -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Sat May 21 17:30:25 2011 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Sat, 21 May 2011 17:30:25 +0200 Subject: [erlang-questions] Recent OTP dev branch dialyzer changes (when-constraints) Message-ID: PRELIMINARIES In the commit, git show 76ca320fd37cecdcf225ddcc094bc72a607b0453 queue.erl commit 76ca320fd37cecdcf225ddcc094bc72a607b0453 Author: Hans Bolinder Date: Fri May 6 15:11:15 2011 +0200 Types and specifications have been modified and added we have the following hunk change: @@ -133,7 +146,10 @@ in_r(X, Q) -> %% Take from head/front %% %% O(1) amortized, O(len(Q)) worst case --spec out(queue()) -> {'empty' | {'value',term()}, queue()}. +-spec out(Q1) -> Result when + Q1 :: queue(), + Q2 :: queue(), + Result :: {{value, Item :: term()}, Q2} | {empty, Q1}. out({[],[]}=Q) -> {empty,Q}; out({[V],[]}) -> QUESTION: I have not seen this style before, and EEP-008 / The Reference documentation makes little reason as to why one would want to change the "polarity" from positive to negative in the spec constraint. * What is the reason for the change? I think the change better reflects the style of other user documentation which is a nice welcome. * I am asking because I don't know why the dialyzer complains in my code. I have a recent branch with the following code: -record(proc_info, { receiver_q :: queue(), sender_q :: queue() }). -opaque t() :: #proc_info{}. -export_type([t/0]). ... -spec dequeue_receiver(t()) -> {ok, term(), t()} | empty. dequeue_receiver(#proc_info { receiver_q = RQ } = PI) -> case queue:out(RQ) of {{value, Item}, NQ} -> {ok, Item, PI#proc_info { receiver_q = NQ }}; {empty, _Q} -> empty end. which uses the queue:out/2 call. And the dialyzer complains: utp_process.erl:49: The specification for utp_process:dequeue_receiver/1 states that the function might also return {'ok',_,utp_process:t()} but the inferred return is 'empty' This puzzles me! Clearly queue:out/2 may return '{empty, queue()}'. Is the dialyzer so strong it guesses RQ is *never* anything but empty? This is odd because if I look at coverage from my test runs, both cases are covered (cue bad formatting if you have a non-monospaced font): | dequeue_receiver(#proc_info { receiver_q = RQ } = PI) -> 124304..| case queue:out(RQ) of | {{value, Item}, NQ} -> 151..| {ok, Item, PI#proc_info { receiver_q = NQ }}; | {empty, _Q} -> 124153..| empty | end. also note that there is only one call-site of dequeue_receiver/1, which leads me to think the dialyzer is wrong here, even though I know the dialyzer is *always right*(tm) :) VERSION OF ERLANG/OTP: Very recent: jlouis@REDACTED:~/Projects/otp$ git describe OTP_R14B02-625-g5f7fa62 Also, ask if more source in my project is needed. If there is any interest I'll try to boil it down to a minimal example. -- J. From alyssa.c.kwan@REDACTED Sat May 21 19:31:59 2011 From: alyssa.c.kwan@REDACTED (Alyssa Kwan) Date: Sat, 21 May 2011 13:31:59 -0400 Subject: [erlang-questions] Mocking I/O calls - defining sequence of returns Message-ID: <312F7919-F0D3-4BDB-AA0F-73951D42209A@gmail.com> Hi everyone! Are there any mocking libraries written that allow you to expect a sequence of calls and return a different value for each call? A mocking library that allows passthrough would be ideal. Thanks! Alyssa From edward.yujiang.wang@REDACTED Sat May 21 19:43:04 2011 From: edward.yujiang.wang@REDACTED (Edward Wang) Date: Sun, 22 May 2011 01:43:04 +0800 Subject: [erlang-questions] Mocking I/O calls - defining sequence of returns In-Reply-To: <312F7919-F0D3-4BDB-AA0F-73951D42209A@gmail.com> References: <312F7919-F0D3-4BDB-AA0F-73951D42209A@gmail.com> Message-ID: Try meck https://github.com/eproxus/meck I used it to mock inet:getifaddrs/0 etc. On Sun, May 22, 2011 at 1:31 AM, Alyssa Kwan wrote: > Hi everyone! > > Are there any mocking libraries written that allow you to expect a sequence > of calls and return a different value for each call? A mocking library that > allows passthrough would be ideal. > > Thanks! > Alyssa > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From igarai@REDACTED Sat May 21 19:44:42 2011 From: igarai@REDACTED (=?UTF-8?B?ScOxYWtpIEdhcmF5?=) Date: Sat, 21 May 2011 14:44:42 -0300 Subject: [erlang-questions] Erlang history Message-ID: Good day Joe, Robert, not that it matters, but do you recall which Prolog implementation you used for the original Erlang compiler? I've read your paper "Use of Prolog for developing a new programming language" from '92, and recall a recorded talk you gave regarding Erlang internals in which you mentioned some historical facts, but could not find this tidbit. kind regards, I?aki Garay. From alyssa.c.kwan@REDACTED Sat May 21 20:40:30 2011 From: alyssa.c.kwan@REDACTED (Alyssa Kwan) Date: Sat, 21 May 2011 14:40:30 -0400 Subject: [erlang-questions] Mocking I/O calls - defining sequence of returns In-Reply-To: References: <312F7919-F0D3-4BDB-AA0F-73951D42209A@gmail.com> Message-ID: I'm sorry, I wasn't being specific. Is there any way to mock a sequence of calls to the same function? Like if I call io:get_line (or a wrapper because it's protected), how do I get it to return a different value for the first call and the second call? Also, will it expect exactly two calls as well? And does meck record call order for different functions? On May 21, 2011, at 1:43 PM, Edward Wang wrote: > Try meck https://github.com/eproxus/meck > > I used it to mock inet:getifaddrs/0 etc. > > On Sun, May 22, 2011 at 1:31 AM, Alyssa Kwan wrote: > Hi everyone! > > Are there any mocking libraries written that allow you to expect a sequence of calls and return a different value for each call? A mocking library that allows passthrough would be ideal. > > Thanks! > Alyssa > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.virding@REDACTED Sat May 21 20:45:22 2011 From: robert.virding@REDACTED (Robert Virding) Date: Sat, 21 May 2011 18:45:22 +0000 (GMT) Subject: [erlang-questions] Erlang history In-Reply-To: <1557190438.207011306003126551.JavaMail.root@zimbra> Message-ID: <350799644.207031306003522333.JavaMail.root@zimbra> Hi I?aki, >From what I can remember it was most likely sicstus prolog. Though it was a long time ago. Robert ----- "I?aki Garay" wrote: > Good day Joe, Robert, > > not that it matters, but do you recall which Prolog implementation you > used for the original Erlang compiler? > I've read your paper "Use of Prolog for developing a new programming > language" from '92, and recall a recorded talk you gave regarding > Erlang internals in which you mentioned some historical facts, but > could not find this tidbit. > > kind regards, > I?aki Garay. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From edward.yujiang.wang@REDACTED Sat May 21 20:55:27 2011 From: edward.yujiang.wang@REDACTED (Edward Wang) Date: Sun, 22 May 2011 02:55:27 +0800 Subject: [erlang-questions] Mocking I/O calls - defining sequence of returns In-Reply-To: References: <312F7919-F0D3-4BDB-AA0F-73951D42209A@gmail.com> Message-ID: Then you will implement your mock version of io:get_line that way. The mock framework merely dispatches the call. That's all. On May 22, 2011 2:40 AM, "Alyssa Kwan" wrote: > I'm sorry, I wasn't being specific. Is there any way to mock a sequence of calls to the same function? Like if I call io:get_line (or a wrapper because it's protected), how do I get it to return a different value for the first call and the second call? > > Also, will it expect exactly two calls as well? And does meck record call order for different functions? > > On May 21, 2011, at 1:43 PM, Edward Wang wrote: > >> Try meck https://github.com/eproxus/meck >> >> I used it to mock inet:getifaddrs/0 etc. >> >> On Sun, May 22, 2011 at 1:31 AM, Alyssa Kwan wrote: >> Hi everyone! >> >> Are there any mocking libraries written that allow you to expect a sequence of calls and return a different value for each call? A mocking library that allows passthrough would be ideal. >> >> Thanks! >> Alyssa >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aronisstav@REDACTED Sat May 21 21:05:35 2011 From: aronisstav@REDACTED (Stavros Aronis) Date: Sat, 21 May 2011 12:05:35 -0700 (PDT) Subject: [erlang-questions] Recent OTP dev branch dialyzer changes (when-constraints) In-Reply-To: Message-ID: <28295931.3632.1306004735505.JavaMail.geo-discussion-forums@vbqe26> Using only the code you provide (exporting therefore the function) I cannot get any warnings. If you could send me some more source I might be able to help on this. -------------- next part -------------- An HTML attachment was scrubbed... URL: From behdad.forghani@REDACTED Sat May 21 21:35:09 2011 From: behdad.forghani@REDACTED (Behdad Forghani) Date: Sat, 21 May 2011 14:35:09 -0500 Subject: [erlang-questions] ASN.1 PER Does Not Correctly Handle Value Range Size Constraint Message-ID: <4DD813ED.6080509@gmail.com> Hi, I have tested this on R14B02. I noticed that ASN.1 compiler does not handle value range size constraints for SEQUENCE OF and BIT STRING. For example: Abs ::= BIT STRING(0|1|7) Bbs ::= BIT STRING(3..18) Cbs ::= BIT STRING Abs has a size constraint of 0..7 and Bbs, 3..18. All three of the above will be encoded identically as length indeterminant as 0x07DA. This is only correct for Cbs. The problem seems to be that encode_bit_string calls get_constraint(C,'SizeConstraint'). However the constraint for the Abs is a UNION and for Bbs a ValueRange. It seems to me the support for both constraints needs to be added. Just FYI, trying to give something back to the community. If I am correct, I can easily fix it. In that case, can you enlighten me on how to submit my code changes? Behdad From mlortiz@REDACTED Sat May 21 21:55:03 2011 From: mlortiz@REDACTED (Marcos Ortiz Valmaseda) Date: Sat, 21 May 2011 15:55:03 -0400 (CDT) Subject: [erlang-questions] Erlang related jobs In-Reply-To: <159451649.6343581306007668809.JavaMail.root@ucimail4.uci.cu> Message-ID: <2126268600.6343761306007703301.JavaMail.root@ucimail4.uci.cu> Regards to all the colleagues here I?m very excited for the exciting moment for Erlang today and I was wondering if exists any mailing list where anyone can post and view Erlang-related jobs and positions, or exists any Erlang Job board (for example http://www.python.org/community/jobs). Thanks a lot -- Marcos Lu?s Ort?z Valmaseda Software Engineer (Large-Scaled Distributed Systems) Universidad de las Ciencias Inform?ticas Linux User # 418229 http://uncubanitolinuxero.blogspot.com http://about.me/marcosortiz From torben.lehoff@REDACTED Sat May 21 21:57:31 2011 From: torben.lehoff@REDACTED (Torben Hoffmann) Date: Sat, 21 May 2011 21:57:31 +0200 Subject: [erlang-questions] Erlang related jobs In-Reply-To: <2126268600.6343761306007703301.JavaMail.root@ucimail4.uci.cu> References: <159451649.6343581306007668809.JavaMail.root@ucimail4.uci.cu> <2126268600.6343761306007703301.JavaMail.root@ucimail4.uci.cu> Message-ID: http://totally-erlang.com/ Cheers, Torben On Sat, May 21, 2011 at 21:55, Marcos Ortiz Valmaseda wrote: > Regards to all the colleagues here > I?m very excited for the exciting moment for Erlang today and I was > wondering if exists any mailing list where anyone can post and view > Erlang-related jobs and positions, or exists any Erlang Job board (for > example http://www.python.org/community/jobs). > > Thanks a lot > > -- > Marcos Lu?s Ort?z Valmaseda > Software Engineer (Large-Scaled Distributed Systems) > Universidad de las Ciencias Inform?ticas > Linux User # 418229 > > http://uncubanitolinuxero.blogspot.com > http://about.me/marcosortiz > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- http://www.linkedin.com/in/torbenhoffmann -------------- next part -------------- An HTML attachment was scrubbed... URL: From spawn.think@REDACTED Sat May 21 22:04:48 2011 From: spawn.think@REDACTED (Ahmed Omar) Date: Sat, 21 May 2011 22:04:48 +0200 Subject: [erlang-questions] Erlang related jobs In-Reply-To: References: <159451649.6343581306007668809.JavaMail.root@ucimail4.uci.cu> <2126268600.6343761306007703301.JavaMail.root@ucimail4.uci.cu> Message-ID: http://www.linkedin.com/groups?careerDiscussion=&gid=90878 On Sat, May 21, 2011 at 9:57 PM, Torben Hoffmann wrote: > http://totally-erlang.com/ > > Cheers, > Torben > > > On Sat, May 21, 2011 at 21:55, Marcos Ortiz Valmaseda wrote: > >> Regards to all the colleagues here >> I?m very excited for the exciting moment for Erlang today and I was >> wondering if exists any mailing list where anyone can post and view >> Erlang-related jobs and positions, or exists any Erlang Job board (for >> example http://www.python.org/community/jobs). >> >> Thanks a lot >> >> -- >> Marcos Lu?s Ort?z Valmaseda >> Software Engineer (Large-Scaled Distributed Systems) >> Universidad de las Ciencias Inform?ticas >> Linux User # 418229 >> >> http://uncubanitolinuxero.blogspot.com >> http://about.me/marcosortiz >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > > > -- > http://www.linkedin.com/in/torbenhoffmann > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think -------------- next part -------------- An HTML attachment was scrubbed... URL: From mlortiz@REDACTED Sat May 21 22:09:30 2011 From: mlortiz@REDACTED (Marcos Ortiz) Date: Sat, 21 May 2011 16:09:30 -0400 Subject: [erlang-questions] Erlang related jobs In-Reply-To: References: <159451649.6343581306007668809.JavaMail.root@ucimail4.uci.cu> <2126268600.6343761306007703301.JavaMail.root@ucimail4.uci.cu> Message-ID: <4DD81BFA.5080306@uci.cu> El 5/21/2011 4:04 PM, Ahmed Omar escribi?: > http://www.linkedin.com/groups?careerDiscussion=&gid=90878 > > > On Sat, May 21, 2011 at 9:57 PM, Torben Hoffmann > > wrote: > > http://totally-erlang.com/ > > Cheers, > Torben > > > On Sat, May 21, 2011 at 21:55, Marcos Ortiz Valmaseda > > wrote: > > Regards to all the colleagues here > I?m very excited for the exciting moment for Erlang today and > I was wondering if exists any mailing list where anyone can > post and view Erlang-related jobs and positions, or exists any > Erlang Job board (for example > http://www.python.org/community/jobs). > > Thanks a lot > > -- > Marcos Lu?s Ort?z Valmaseda > Software Engineer (Large-Scaled Distributed Systems) > Universidad de las Ciencias Inform?ticas > Linux User # 418229 > > http://uncubanitolinuxero.blogspot.com > http://about.me/marcosortiz > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > > -- > http://www.linkedin.com/in/torbenhoffmann > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > > -- > Best Regards, > - Ahmed Omar > http://nl.linkedin.com/in/adiaa > Follow me on twitter > @spawn_think > Thanks a lot for the quick reponses. Regards -- Marcos Lu?s Ort?z Valmaseda Software Engineer (Large-Scaled Distributed Systems) University of Information Sciences, La Habana, Cuba Linux User # 418229 http://about.me/marcosortiz -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebegumisa@REDACTED Sun May 22 00:01:09 2011 From: ebegumisa@REDACTED (Edmond Begumisa) Date: Sun, 22 May 2011 08:01:09 +1000 Subject: [erlang-questions] QuickCheck Message-ID: Hello all, I'm a QuickCheck noob trying out PropEr. Actually, I'm very embarrassed to admit that I'm very new to formal testing in general (I've always done things in the ad-hoc way for longer than I care to admit). I only confess to this coz I probably wouldn't get away with lying about it on *this* list when I start asking stupid questions! Anyways, I'm having A LOT of trouble getting started. The initial inertia just isn't there. Even with the available documentation from both QuviQ and PropEr. I look at my code and don't know where to begin writing tests for it! A sad state of affairs. I think I just need a few good tutorials. Can anyone recommend some QuickCheck resources to get me going that they've actually successfully used? Do I need to first start out with more "traditional" testing tools first before even attempting QuickCheck? Thanks in advance for you help. - Edmond - -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From jameschurchman@REDACTED Sun May 22 00:07:32 2011 From: jameschurchman@REDACTED (James Churchman) Date: Sat, 21 May 2011 23:07:32 +0100 Subject: [erlang-questions] Mocking I/O calls - defining sequence of returns In-Reply-To: References: <312F7919-F0D3-4BDB-AA0F-73951D42209A@gmail.com> Message-ID: as erlang is functional by default you always get the same result every time you call a pure function. you have to either place in a random ( is random a "pure" thing? ) that randomly selects an output each time, or you need to store the number of calls in an impure way. The options would be to spawn off a process ( eg a genserver ) in the background and have your mock code talk to it, start an ets table, maybe even * write to a file * tho i get that defeats the purpose of what your trying to do, or as a cheep trick use the process dictionary: first put a starting value in the PD : put(number_of_runs,0) then in your code you can : case Runs = get(number_of_runs) & put(number_of_runs,Runs+1) & erase at the end : erase(number_of_runs) http://www.erlang.org/course/advanced.html#dict tho use of the process dictionary makes debugging& understanding the code etc.... very tricky and breaks most of the elegant parts of erlang, so its best used for the kinds of uses you have in mind and less so in your real code :-) On 21 May 2011 19:55, Edward Wang wrote: > Then you will implement your mock version of io:get_line that way. The mock > framework merely dispatches the call. That's all. > On May 22, 2011 2:40 AM, "Alyssa Kwan" wrote: > > I'm sorry, I wasn't being specific. Is there any way to mock a sequence > of calls to the same function? Like if I call io:get_line (or a wrapper > because it's protected), how do I get it to return a different value for the > first call and the second call? > > > > Also, will it expect exactly two calls as well? And does meck record call > order for different functions? > > > > On May 21, 2011, at 1:43 PM, Edward Wang wrote: > > > >> Try meck https://github.com/eproxus/meck > >> > >> I used it to mock inet:getifaddrs/0 etc. > >> > >> On Sun, May 22, 2011 at 1:31 AM, Alyssa Kwan > wrote: > >> Hi everyone! > >> > >> Are there any mocking libraries written that allow you to expect a > sequence of calls and return a different value for each call? A mocking > library that allows passthrough would be ideal. > >> > >> Thanks! > >> Alyssa > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questions@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-questions > >> > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jameschurchman@REDACTED Sun May 22 01:44:23 2011 From: jameschurchman@REDACTED (James Churchman) Date: Sun, 22 May 2011 00:44:23 +0100 Subject: [erlang-questions] Advanced Erlang Subtleties In-Reply-To: References: <20110520034535.GA6320@mulga.csse.unimelb.edu.au> Message-ID: a final one.. if you have for example a record like : -record(server_opts,{port, ip="127.0.0.1", max_connections=10}). then you can obviously do : make_a_record()->#server_opts{max_connections=100}. and to update a record : update_a_record()-> MyRec = make_a_record(), MyUpdatedRec = MyRec#server_opts{ip="10.20.30.40"}. but you can't skip out the intermediate variable like so : update_a_record()-> make_a_record()#server_opts{ip="10.20.30.40"}. it gives ":17: syntax error before: '#'" but wrapping in round brackets allows this : update_a_record()-> (make_a_record())#server_opts{ip="10.20.30.40"}. not sure why this is they case, but anyhow this might save a few lines :-) On 20 May 2011 18:02, James Churchman wrote: > yes this is where i think erlang really gets the balance correct, being > dynamically typed ( so far less repetitive defining types where the type is > either obvious or does not matter and is just begin "messaged" threw .. tho > i know other people are strongly in favour of static typing) but not > Loosely Typed so avoids the huge amounts of ambiguity like what happens when > you "add" or "subtract" different types as does JS, leading to the bug > showing up a huge distance way from the code that was at fault.. > unfortunately JS also has hundreds of faults & bugs ( around 270 at my count > ;-) ) in the original implementation that due to a big of a chicken / egg > scenario cant really ever be changed :-) things like "crashing late" come > from the fact that early versions had no error handling at all! ( eg no try > catch ) > > >A nice example of how semantics is so much more important than syntax? > > yes and shows that purely putting new syntax's onto an existing language > only aid developer productivity & readability a bit and generally don't make > the code (much) more reliable > > On Fri, May 20, 2011 at 5:45 AM, Jeff Schultz wrote: > >> On Thu, May 19, 2011 at 11:02:35PM +0200, Joe Armstrong wrote: >> > > I can see the equivalent evaluation of "250"<250 being a common >> mistake, >> > > and always being false is hardly useful. >> >> > A "<" B when A and B have different types means A is >> > "less complex" than B. Lists and more complex than integers >> > "250" is a list so "250"<250 is false. >> > > Another thought I had about this was that in some languages > "10" < 20 might be true, and "20" < 10 or 20 < "10" might be false. > > In Erlang a string (list) is always bigger (ie more complex) than an > integer. > > A Javascript programmer might get confused here. > > Erlang: > > "12" + 1 => (exception) > "12" - 1 => (exception) > "12" > 2 => true > "12" > 15 => true > > Javascript: > > "12" + 1 => "121" > "12" - 1 => 11 > "12" > 2 => true > "12" > 15 => false > > Overloading plus to mean either plus or string concatenation is > horrible - and shouldn't "-" mean string subtraction (sometimes) > > so "123" - 23 =>100 and "abc" - "a" => "bc" and "abc" - "c" => "ab" > :-) > > I prefer the Erlang method - but then I'm probably somewhat biased here... > > This (Javascript) horrible way of doing things caused me > hours of debugging - since my debugger wrote strings without > the quotes so I couldn't see the difference between "123" and 123 > when printed. > > Javascript also crashes late, and variables in closures > can be changed after binding them into the closures ... and the > concurrency model is ... (isn't) - but it's fun to muck around with > and do things in the browser. > > >> > Suppose I want to make a Key-Value database, where the Key can be >> anything, >> > including 250 and "250" to make any form of ordered tree we need a total >> > order over all the keys. >> >> Indeed. If we can have only one built-in comparison, it needs to be >> total over all values. It is a pity that Prolog's distinction between >> term comparison and number comparison wasn't carried over to Erlang :-( >> >> >> Jeff Schultz >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.schlager@REDACTED Sun May 22 05:45:44 2011 From: tobias.schlager@REDACTED (Tobias Schlager) Date: Sun, 22 May 2011 05:45:44 +0200 Subject: [erlang-questions] Mocking I/O calls - defining sequence of returns In-Reply-To: References: <312F7919-F0D3-4BDB-AA0F-73951D42209A@gmail.com> Message-ID: <4DD886E8.6040009@lindenbaum.eu> Hi, you could try erlymock. It's usage is pretty much like easymock for java. Link: * https://github.com/sheyll/erlymock For your example you could write something like this: M = em:new(), em:strict(M, io, get_line, [prompt1], {return, "a line"}), em:strict(M, io, get_line, [prompt2], {return, eof}), em:replay(M), ... test code goes here ... em:verify(M), I don't know how other frameworks do it but mocking io:get_line with erlymock will purge the io module. So running your test from within an erlang shell will most likely break the running shell. Regarding this mocking the io module might not be a good idea. Regards Tobias Am 21.05.2011 20:55, schrieb Edward Wang: > Then you will implement your mock version of io:get_line that way. The > mock framework merely dispatches the call. That's all. > > On May 22, 2011 2:40 AM, "Alyssa Kwan" > wrote: > > I'm sorry, I wasn't being specific. Is there any way to mock a > sequence of calls to the same function? Like if I call io:get_line (or a > wrapper because it's protected), how do I get it to return a different > value for the first call and the second call? > > > > Also, will it expect exactly two calls as well? And does meck record > call order for different functions? > > > > On May 21, 2011, at 1:43 PM, Edward Wang wrote: > > > >> Try meck https://github.com/eproxus/meck > >> > >> I used it to mock inet:getifaddrs/0 etc. > >> > >> On Sun, May 22, 2011 at 1:31 AM, Alyssa Kwan > > wrote: > >> Hi everyone! > >> > >> Are there any mocking libraries written that allow you to expect a > sequence of calls and return a different value for each call? A mocking > library that allows passthrough would be ideal. > >> > >> Thanks! > >> Alyssa > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questions@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-questions > >> > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From anthonym@REDACTED Sun May 22 08:15:59 2011 From: anthonym@REDACTED (Anthony Molinaro) Date: Sat, 21 May 2011 23:15:59 -0700 Subject: [erlang-questions] QuickCheck In-Reply-To: References: Message-ID: <20110522061559.GB61519@alumni.caltech.edu> On Sun, May 22, 2011 at 08:01:09AM +1000, Edmond Begumisa wrote: > I'm a QuickCheck noob trying out PropEr. Actually, I'm very > embarrassed to admit that I'm very new to formal testing in general > (I've always done things in the ad-hoc way for longer than I care to > admit). I only confess to this coz I probably wouldn't get away with > lying about it on *this* list when I start asking stupid questions! I'm mostly a noob myself, but I have used both quickcheck and proper and figured anything helps when you're just learning these tools. > Anyways, I'm having A LOT of trouble getting started. The initial > inertia just isn't there. Even with the available documentation from > both QuviQ and PropEr. I look at my code and don't know where to > begin writing tests for it! A sad state of affairs. The one thing to remember is that there are many types of testing and quickcheck/proper focus on randomized testing of properties. Getting you head around testing in that fashion can be a challenge, it forces you to think about generating random data for which you know the answer. Quickcheck and proper excel at problems where you have a function and it's reverse (like encode and decode), because the property of decode (encode (Data)) == Data is pretty easy to setup, you just supply random Data and let it run for a few hundred thousand tests. For other functions where you don't have an inverse the trick is knowing the answer when you give it random data (at least this is what I've found with my limited use of these tools). Other testing frameworks like eunit or common_test may be more of what you are looking for, but it really depends on what you are testing. If you have a general description of the code, I might be able to make some suggestions, but its hard to say without know what you are trying to test. > I think I just need a few good tutorials. Can anyone recommend some > QuickCheck resources to get me going that they've actually > successfully used? Do I need to first start out with more > "traditional" testing tools first before even attempting QuickCheck? There are a few nice examples here http://www.trapexit.org/Category:QuickCheck There are also a few videos and other things if you search for erlang quickcheck tutorial on your favorite search engine. Hope that helps, -Anthony -- ------------------------------------------------------------------------ Anthony Molinaro From john.hughes@REDACTED Sun May 22 12:20:06 2011 From: john.hughes@REDACTED (John Hughes) Date: Sun, 22 May 2011 12:20:06 +0200 Subject: [erlang-questions] QuickCheck In-Reply-To: References: Message-ID: <319EB5973BAA42579692F3000F036E22@JohnsTablet2009> Hi Edmond, You're not alone--there is a hurdle to get over, a different way of thinking about testing. My talk at the last Erlang Factory in SF was specifically intended to help people just starting out--the video and slides are on the web at http://www.erlang-factory.com/conference/SFBay2011/speakers/JohnHughes. Be interested to hear if you find it helpful/not helpful. John ----- Original Message ----- From: "Edmond Begumisa" To: Sent: Sunday, May 22, 2011 12:01 AM Subject: [erlang-questions] QuickCheck > Hello all, > > I'm a QuickCheck noob trying out PropEr. Actually, I'm very embarrassed to > admit that I'm very new to formal testing in general (I've always done > things in the ad-hoc way for longer than I care to admit). I only confess > to this coz I probably wouldn't get away with lying about it on *this* > list when I start asking stupid questions! > > Anyways, I'm having A LOT of trouble getting started. The initial inertia > just isn't there. Even with the available documentation from both QuviQ > and PropEr. I look at my code and don't know where to begin writing tests > for it! A sad state of affairs. > > I think I just need a few good tutorials. Can anyone recommend some > QuickCheck resources to get me going that they've actually successfully > used? Do I need to first start out with more "traditional" testing tools > first before even attempting QuickCheck? > > Thanks in advance for you help. > > - Edmond - > > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > From erlang@REDACTED Sun May 22 14:42:24 2011 From: erlang@REDACTED (Joe Armstrong) Date: Sun, 22 May 2011 14:42:24 +0200 Subject: [erlang-questions] Erlang history In-Reply-To: <350799644.207031306003522333.JavaMail.root@zimbra> References: <1557190438.207011306003126551.JavaMail.root@zimbra> <350799644.207031306003522333.JavaMail.root@zimbra> Message-ID: Sicstus came later - first was mu prolog from Melborne. ( I don't thing sicstus was released in 1986) - I think we then bought quintus prolog - mu prolog only did GC on backtracking. We also bought the first every licence for ALS prolog so we could run on a PC /Joe On Sat, May 21, 2011 at 8:45 PM, Robert Virding < robert.virding@REDACTED> wrote: > Hi I?aki, > > From what I can remember it was most likely sicstus prolog. Though it was a > long time ago. > > Robert > > ----- "I?aki Garay" wrote: > > > Good day Joe, Robert, > > > > not that it matters, but do you recall which Prolog implementation you > > used for the original Erlang compiler? > > I've read your paper "Use of Prolog for developing a new programming > > language" from '92, and recall a recorded talk you gave regarding > > Erlang internals in which you mentioned some historical facts, but > > could not find this tidbit. > > > > kind regards, > > I?aki Garay. > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebegumisa@REDACTED Sun May 22 19:57:15 2011 From: ebegumisa@REDACTED (Edmond Begumisa) Date: Mon, 23 May 2011 03:57:15 +1000 Subject: [erlang-questions] QuickCheck In-Reply-To: <20110522061559.GB61519@alumni.caltech.edu> References: <20110522061559.GB61519@alumni.caltech.edu> Message-ID: On Sun, 22 May 2011 16:15:59 +1000, Anthony Molinaro wrote: > > On Sun, May 22, 2011 at 08:01:09AM +1000, Edmond Begumisa wrote: >> I'm a QuickCheck noob trying out PropEr. Actually, I'm very >> embarrassed to admit that I'm very new to formal testing in general >> (I've always done things in the ad-hoc way for longer than I care to >> admit). I only confess to this coz I probably wouldn't get away with >> lying about it on *this* list when I start asking stupid questions! > > I'm mostly a noob myself, but I have used both quickcheck and proper > and figured anything helps when you're just learning these tools. > >> Anyways, I'm having A LOT of trouble getting started. The initial >> inertia just isn't there. Even with the available documentation from >> both QuviQ and PropEr. I look at my code and don't know where to >> begin writing tests for it! A sad state of affairs. > > The one thing to remember is that there are many types of testing > and quickcheck/proper focus on randomized testing of properties. > Getting you head around testing in that fashion can be a challenge, > it forces you to think about generating random data for which you > know the answer. Quickcheck and proper excel at problems where > you have a function and it's reverse (like encode and decode), because > the property of decode (encode (Data)) == Data is pretty easy to setup, > you just supply random Data and let it run for a few hundred thousand > tests. For other functions where you don't have an inverse the trick > is knowing the answer when you give it random data (at least this > is what I've found with my limited use of these tools). > > Other testing frameworks like eunit or common_test may be more of > what you are looking for, but it really depends on what you are > testing. If you have a general description of the code, I might > be able to make some suggestions, but its hard to say without > know what you are trying to test Firstly, I have a few general purpose libraries. Mainly extensions to existing standard libraries like my_lists.erl, my_binaries.erl, my_proplists.erl, etc. Auto-testing these is probably not that important. But my guess is it would be a good place to start for simplicity. Secondly, I also have a TCP socket application that's designed to have pluggable codecs. The idea being I can just plugin a module called http_codec.beam, and the socket server starts doing http. Then I can plugin websocket_codec.beam on top of that and it starts doing websocks over http. Then I can remove those and plugin ubf_codec.beam, and it starts doing UBF over TCP. You get the picture. The socket server is the usual multi-acceptor (gen_server), spawn new connections (gen_fsm) setup. The codecs are just plain modules with decode/encode functions that continue from where they last left off. I really want to test this coz it's at the center of all the apps I'm developing and frequently misbehaves in annoying little ways that I should have foreseen but don't realise til it actually happens (little perfect storms creep up on me.) I figure automated testing is they only solution. Thirdly, most of the products I'm working on make heavy use of state machines that sit on top of the socket toolkit described above. These are application specific and need testing too. Oh, and these interact frequently with CouchDB. That's the basic picture. I want to start testing ALL of this :P Any more tips would be great. Thanks. - Edmond - > >> I think I just need a few good tutorials. Can anyone recommend some >> QuickCheck resources to get me going that they've actually >> successfully used? Do I need to first start out with more >> "traditional" testing tools first before even attempting QuickCheck? > > There are a few nice examples here > > http://www.trapexit.org/Category:QuickCheck > > There are also a few videos and other things if you search for > erlang quickcheck tutorial on your favorite search engine. > > Hope that helps, > > -Anthony > > -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From ebegumisa@REDACTED Sun May 22 20:12:05 2011 From: ebegumisa@REDACTED (Edmond Begumisa) Date: Mon, 23 May 2011 04:12:05 +1000 Subject: [erlang-questions] QuickCheck In-Reply-To: References: <20110522061559.GB61519@alumni.caltech.edu> Message-ID: On Mon, 23 May 2011 03:57:15 +1000, Edmond Begumisa wrote: > On Sun, 22 May 2011 16:15:59 +1000, Anthony Molinaro > wrote: > >> >> On Sun, May 22, 2011 at 08:01:09AM +1000, Edmond Begumisa wrote: >>> I'm a QuickCheck noob trying out PropEr. Actually, I'm very >>> embarrassed to admit that I'm very new to formal testing in general >>> (I've always done things in the ad-hoc way for longer than I care to >>> admit). I only confess to this coz I probably wouldn't get away with >>> lying about it on *this* list when I start asking stupid questions! >> >> I'm mostly a noob myself, but I have used both quickcheck and proper >> and figured anything helps when you're just learning these tools. >> >>> Anyways, I'm having A LOT of trouble getting started. The initial >>> inertia just isn't there. Even with the available documentation from >>> both QuviQ and PropEr. I look at my code and don't know where to >>> begin writing tests for it! A sad state of affairs. >> >> The one thing to remember is that there are many types of testing >> and quickcheck/proper focus on randomized testing of properties. >> Getting you head around testing in that fashion can be a challenge, >> it forces you to think about generating random data for which you >> know the answer. Quickcheck and proper excel at problems where >> you have a function and it's reverse (like encode and decode), because >> the property of decode (encode (Data)) == Data is pretty easy to setup, >> you just supply random Data and let it run for a few hundred thousand >> tests. For other functions where you don't have an inverse the trick >> is knowing the answer when you give it random data (at least this >> is what I've found with my limited use of these tools). >> >> Other testing frameworks like eunit or common_test may be more of >> what you are looking for, but it really depends on what you are >> testing. If you have a general description of the code, I might >> be able to make some suggestions, but its hard to say without >> know what you are trying to test > > Firstly, I have a few general purpose libraries. Mainly extensions to > existing standard libraries like my_lists.erl, my_binaries.erl, > my_proplists.erl, etc. Auto-testing these is probably not that > important. But my guess is it would be a good place to start for > simplicity. > > Secondly, I also have a TCP socket application that's designed to have > pluggable codecs. The idea being I can just plugin a module called > http_codec.beam, and the socket server starts doing http. Then I can > plugin websocket_codec.beam on top of that and it starts doing websocks > over http. Then I can remove those and plugin ubf_codec.beam, and it > starts doing UBF over TCP. You get the picture. > > The socket server is the usual multi-acceptor (gen_server), spawn new > connections (gen_fsm) setup. The codecs are just plain modules with > decode/encode functions that continue from where they last left off. I > really want to test this coz it's at the center of all the apps I'm > developing and frequently misbehaves in annoying little ways that I > should have foreseen but don't realise til it actually happens (little > perfect storms creep up on me.) I figure automated testing is they only > solution. And I also figured I could use QuickCheck/PropEr to create these scenarios that I can't seem to foresee! - Edmond - > > Thirdly, most of the products I'm working on make heavy use of state > machines that sit on top of the socket toolkit described above. These > are application specific and need testing too. Oh, and these interact > frequently with CouchDB. > > That's the basic picture. I want to start testing ALL of this :P Any > more tips would be great. > > Thanks. > > - Edmond - > >> >>> I think I just need a few good tutorials. Can anyone recommend some >>> QuickCheck resources to get me going that they've actually >>> successfully used? Do I need to first start out with more >>> "traditional" testing tools first before even attempting QuickCheck? >> >> There are a few nice examples here >> >> http://www.trapexit.org/Category:QuickCheck >> >> There are also a few videos and other things if you search for >> erlang quickcheck tutorial on your favorite search engine. >> >> Hope that helps, >> >> -Anthony >> >> > > -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From robert.virding@REDACTED Sun May 22 23:45:08 2011 From: robert.virding@REDACTED (Robert Virding) Date: Sun, 22 May 2011 21:45:08 +0000 (GMT) Subject: [erlang-questions] Erlang history In-Reply-To: <2106282401.208291306100638006.JavaMail.root@zimbra> Message-ID: <220785688.208311306100708694.JavaMail.root@zimbra> Are you sure? I remember mu-prolog but I can't remember using it. Also ALS prolog which in the old days had a different more s-expr based syntax. Robert ----- "Joe Armstrong" wrote: > Sicstus came later - first was mu prolog from Melborne. > ( I don't thing sicstus was released in 1986) - I think we then > bought quintus prolog - mu prolog only did GC on backtracking. > We also bought the first every licence for ALS prolog so we could > run on a PC > > /Joe > > > > > On Sat, May 21, 2011 at 8:45 PM, Robert Virding < robert.virding@REDACTED > wrote: > Hi I?aki, > > From what I can remember it was most likely sicstus prolog. Though it was a long time ago. > > Robert > > > ----- "I?aki Garay" < igarai@REDACTED > wrote: > > > Good day Joe, Robert, > > > > not that it matters, but do you recall which Prolog implementation you > > used for the original Erlang compiler? > > I've read your paper "Use of Prolog for developing a new programming > > language" from '92, and recall a recorded talk you gave regarding > > Erlang internals in which you mentioned some historical facts, but > > could not find this tidbit. > > > > kind regards, > > I?aki Garay. > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.virding@REDACTED Mon May 23 00:26:01 2011 From: robert.virding@REDACTED (Robert Virding) Date: Sun, 22 May 2011 22:26:01 +0000 (GMT) Subject: [erlang-questions] AST record syntax improvement In-Reply-To: <1801378050.208491306103137344.JavaMail.root@zimbra> Message-ID: <869690838.208511306103161268.JavaMail.root@zimbra> I think the actual syntax is the least of your problems. The existing syntax looks like it does much because of the properties of erlang and of records. Records were added to give named fields to tuples and to be at least as fast as directly using the tuple operations. This means that everything had to be done at compile-time. And as erlang is dynamically typed without any typed declarations then all type information has to be given at each record operation. Recless tried to be smart and get around this and only require the field names and not the record names. There are really only two ways of doing this properly: 1. Require that all field names are unique in all records. 2. Require some typing "help" so the system can work out which record types are being accessed. The first is very difficult to work with in any large project. It would even be difficult for all OTP records. The second would mean requiring static type declarations to work properly and in all situations, which would be a fundamental change to the current Erlang language. It would, in fact, be a new language. Another thing to be aware of is that pattern matching and '=' complicate the syntax. I personally don't think that NewProject = Project.owner.address.city = "Boston". is that much more intelligible. The record replacement you mention is NOT a a replacement for records as they are too firmly entrenched into the whole system to be removed, or even modified. It is a new data type which does contains named fields but is a dynamic data structure. Like giving dicts a special syntax, or like hashmaps in other languages. Robert ----- "James Churchman" wrote: > Doubt im alone in saying that the record syntax is not only poor, but very acidic to erlang programming. It moves the balance of when you should stop using a tuple and over to a record strongly to the "il keep using a tuple thanks" end of things. There was one attempt ( maybe two ) to fix records but it had a few problems : > the good points: 1) the accessor pattern was great, and ever better for accessing records in records. something not easy in the regular syntax!! 2) its better than the normal record syntax! 3) it auto detected records, but just within that one function, by noticing the first time it was used as a record. 4) it added 0 performance penalty for using this new syntax > the not so good points :-) : > 1) it was very unreliable, totally unrelated to records erlang code would randomly break and your left debugging a parse transform that's very deep, half way threw, all your code. 2) updater code was kinda bad & weird and also made other valid erlang code into something else 3) maybe a small point, but if you are shipping code to clients, they may not like code that ships with dependancies on unsupported parse-transform libraries 4) if you have one record that spans almost all your code in that module, you still have to repeat the fact its a record at least once in every function > here is is from all the way back in 2006 > http://yarivsblog.blogspot.com/2006/10/recless-type-inferring-parse-transform.html > I know there has been some talk of a record replaclemnt in Erl/OTP but i am planing on producing my own in the meantime, from a *simplified* AST parse transform and the syntax would look like this: > > Accessing : Value = RecordTypeVariable.element1.sub_element_of_elemet_1 etc.. just like recless ( also without "=" match like do_func(RecordTypeVariable.element1) ) > No multiple access, its not really needed in this case > Updating : NewRec = RecordTypeVariable(element1.sub_element_of_elemet_1="mynewvalue",element2="mynewvalue_for_element2"). > This combines the record syntax with the fun syntax, so looks semi-familiar and importantly will not produce a syntax error before the parse transform ( otherwise i could have the updater with {}). The alternate is to mix with record syntax with the (no so popular) PMod syntax like RecordTypeVar:rec_update(element1.elem1_sub_elem=....) > if the same record is used throughout, it would be possible, but entirly optional, to set a "global record" for the module, so any var name matching that "global record" would be auto set eg : -global_record(state,['State']). ( single quotes needed to make the capital value an atom ) > Producing a revers that generates the original record syntax for shipping to clients would be useful i feel too! > So any thoughts on my updater syntax? or suggestions that could be better ( keeping i mind that it still has to pass the first step of parsing!) > James > _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Mon May 23 03:33:40 2011 From: ok@REDACTED (Richard O'Keefe) Date: Mon, 23 May 2011 13:33:40 +1200 Subject: [erlang-questions] call by value In-Reply-To: <4DD6578F.7040105@gmail.com> References: <4DD538E2.70107@gmail.com> <4DD56A76.1050303@gmail.com> <5EEE88DE-75FD-4452-B981-FB47C8FD8A93@cs.otago.ac.nz> <4DD6578F.7040105@gmail.com> Message-ID: <73C1BC93-4DB1-4CAC-BA13-87837FB32969@cs.otago.ac.nz> On 20/05/2011, at 11:59 PM, Martin Dimitrov wrote: > >> but for "values" that are (references to) linked structures, >> no copying is done. >> > If you are talking about Java, isn't this copy-by-reference? I've never seen the term "copy-by-reference" before, so I can't tell. It certainly isn't PASS by reference. void incr(int &x) { x++; } int main(void) { int b = 2; incr(b); cout << b << endl; } in C++ (a) uses pass by reference, and (b) prints 3. You cannot do that in Java. Java has pass by value and ONLY pass by value. Some of those values are (perhaps confusingly) called "object references" (in practice they are almost always just plain pointers, something Java is, again misleadingly, said not to have)., From ok@REDACTED Mon May 23 03:49:41 2011 From: ok@REDACTED (Richard O'Keefe) Date: Mon, 23 May 2011 13:49:41 +1200 Subject: [erlang-questions] Efficiency of a list construction In-Reply-To: <20110520123852.GA5211@erix.ericsson.se> References: <20110520105035.GK11339@aluminum.local> <8E910913-40E2-4C0D-B375-985D72E7FDAF@erlang-solutions.com> <20110520123852.GA5211@erix.ericsson.se> Message-ID: <700ADECC-FB6A-4EFC-80ED-2183DFD34BEB@cs.otago.ac.nz> Consider map(F, [X|Xs]) -> [F(X) | map(F, Xs)]; map(_, [] ) -> []. By the classical definition, this is not tail recursive. The Prolog equivalent, however, _is_. The reason the Prolog version is tail recursive is that it can build a data structure with a hole in it [F(X) | Hole] and pass the hole: map(F, [X|Xs], &Result) => *Result := [F(X) | Hole], map(F, Xs, &Hole); map(F, [], &Result) => *Result := []. And this would be safe even in Erlang because nobody (other than the garbage collector) can ever see the hole. This extended version of "tail recursion" applies when there the last expression that the call occurs in is a data structure construction. The existing Erlang system *doesn't* support extended tail recursion, largely for the sake of the garbage collector. But it could, without any change to the source language or its semantics. From ok@REDACTED Mon May 23 04:00:53 2011 From: ok@REDACTED (Richard O'Keefe) Date: Mon, 23 May 2011 14:00:53 +1200 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: <661C1ED1-0683-435C-8BF0-5EAB2289D546@erlang-solutions.com> <3E70F4ECA6ED459C936583EE3B7301EC@srstrong.com> Message-ID: On 21/05/2011, at 1:57 AM, Michael Turner wrote: > "... looking at both backward *and* forward compatibility issues (what sort of things might this change prevent us from doing in the future?)" > > I have repeatedly asked people here what this change would break, and in particular how it might compromise backward compatibility. Nobody has answered, so far. That's principally because people find the proposed change so disgusting that they don't greatly _care_ whether it is compatible or not; it's not compatible with *them*. > Since the change amounts to the compiler silently inserting a function name during parsing at points where some IDE environments already already insert the name literally when you type ";", it's pretty hard to see how there could be a backward compatibility issue. If you mean "could there be existing code whose meaning would be altered by this proposal", the answer is "no". If you mean "could existing tools, including third-party tools, handle this", the answer is "no, definitely not". > > "Emacs for one would need work since it's syntax highlighting would now be broken." > > It would only be broken for any code that took advantage of the change I suggest. The thing is that the number of people who took advantage of it is unknown and and the amount of code that would be affected is unknown and how fast the change would be adopted is unknown, so somebody using a well trusted tool would NEVER KNOW WHETHER IT WAS GOING TO BREAK on some file maintained by someone else. When the new syntax is in support of some new *semantics* that we have a need for, such as the introduction of 'fun's in the first place, then that is a price that can be worth paying. When the new syntax is merely syntactic strychnine, no. > Which would start out at exactly zero percent of the Erlang code out there. As the supposed "harm" grew, well, somebody would go and modify whatever needed to be modified, to make syntax highlighting work as it does in Emacs already for the analogous syntax in Clojure. > > "If this is so important to you ...." > > It is not that important to me (at the moment.) Then why are you wasting our time arguing for it? I've written a working parser for someone else's language in less of my time than you've wasted. If you care about it, implement it yourself or pay someone else to. > However, like anybody else, I hate having my case for change twisted by others, and I hate objections to ideas (mine and others) when the objections don't actually hold water. I haven't noticed anyone twisting your idea or your case for. You case is simply that it removes an "inconsistency" which nobody else seems to perceive as an inconsistency (or if they do, as one that needs fixing at the *other* end) and reduces an already trivial amount of typing and makes the language look more like other languages that many Erlang programmers have gladly abandoned. From ok@REDACTED Mon May 23 04:23:50 2011 From: ok@REDACTED (Richard O'Keefe) Date: Mon, 23 May 2011 14:23:50 +1200 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: <749E5278-61D7-4A58-82D0-A128D0972C97@cs.otago.ac.nz> Message-ID: On 21/05/2011, at 2:11 AM, Michael Turner wrote: > "It seems to me that Michael Turner's argument is an argument from conservatism. > Algol, Basic, COBOL, Fortran, PL/I, Simula, XPL, Java, Javascript, PHP, Perl, > all of these languages write a function name once and only once at the beginning > of a function." > > But which of those allow more than one argument list? It's not quite clear to me what you mean here, but add(x)to:(y)giving:(z)and:(w) is perfectly good Algol 60. Javascript allows things like f(1)(2). And of course, anyone who knows Fortran knows that a Fortran subprogram may have multiple entry points, and so multiple formal parameter lists. If you mean "allow more than one CLAUSE", then the answer is that the languages that allow more than one clause in a named function repeat the name, just like Erlang. > I think the indentation style I suggest also makes it more immediately obvious that Erlang features a kind of pattern-directed invocation. People who are entirely new to Erlang are also entirely new to the idea of pattern directed invocation, and if they aren't, they are also not new to the idea of repeating the function name. If you are new to pattern directed invocation, your indentation is not going to help one iota: one left parenthesis or square bracket looks much like another. I will go this far: the discrepancy between functions and funs *is* a problem. But it is the *funs* that are the problem, and the remedy is to let them have names also. Allowing names in funs is not a case of syntactic strychnine; not even a case of syntactic sugar. It actually provides new and desired semantics (directly recursive funs), so it is at least _possible_ that it might repay the cost of adopting it. As things stand, I must say that I find multiclause funs in the usual indentation style (that is, in the indentation style you are recommending for normal functions) quite unreadable. > > As for what you claim is more readable, remember: the intuitive is the familiar. Someone who is entirely new to Erlang will perceive things differently. The people who actually *teach* Erlang to people who have not met us before tell us that they actually pick it up fairly easily. > The only way to make the proposition "syntax X is more readable" a scientific one is to test -- on people *new* to Erlang. Wrong. What a tricky way to load the case in your favour! The people who are entirely new to the language are the very LAST people you should study; then you are measuring LEARNABILITY (or more FAMILIARITY), not READABILITY. The kind of readability that matters is readability to people who have *some* experience with the language. People who have at least troubled to read an Erlang book all the way through, and can be bothered to read the Erlang reference manual once all the way through. By the time you get that far, you are not "entirely new" any more. I can tell you this: I went from knowing practically all the classic 60s and 70s programming languages (including ones you've probably never heard of), including Lisp, to learning Prolog. And one thing that never EVER gave me the slightest trouble whatsoever was having the name of a predicate repeated in each clause. From ok@REDACTED Mon May 23 04:25:48 2011 From: ok@REDACTED (Richard O'Keefe) Date: Mon, 23 May 2011 14:25:48 +1200 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: <1930B4D4-54DD-4F80-ACDE-BBE983315E64@hates.ms> <1799C0B6-EA5B-469E-94EE-18F3F3A16C52@cs.otago.ac.nz> Message-ID: <109F5B57-5B44-4300-B1A6-1A17EF6F6C95@cs.otago.ac.nz> On 21/05/2011, at 2:13 AM, Michael Turner wrote: > "And why do you think I don't use Clojure?" > > Uh, Richard, where did he say he thought that? He didn't, and I don't know why you think I think he thought that. I was simply making the point that precisely because "this is name-less clause syntax is the same as in Clojure" it would be just as much a horrible mistake in Erlang as it is in Clojure. > From dan@REDACTED Mon May 23 04:29:58 2011 From: dan@REDACTED (Daniel Dormont) Date: Sun, 22 May 2011 22:29:58 -0400 Subject: [erlang-questions] call by value In-Reply-To: <73C1BC93-4DB1-4CAC-BA13-87837FB32969@cs.otago.ac.nz> References: <4DD538E2.70107@gmail.com> <4DD56A76.1050303@gmail.com> <5EEE88DE-75FD-4452-B981-FB47C8FD8A93@cs.otago.ac.nz> <4DD6578F.7040105@gmail.com> <73C1BC93-4DB1-4CAC-BA13-87837FB32969@cs.otago.ac.nz> Message-ID: On Sun, May 22, 2011 at 9:33 PM, Richard O'Keefe wrote: > > On 20/05/2011, at 11:59 PM, Martin Dimitrov wrote: > > > > >> but for "values" that are (references to) linked structures, > >> no copying is done. > >> > > If you are talking about Java, isn't this copy-by-reference? > > I've never seen the term "copy-by-reference" before, > so I can't tell. It certainly isn't PASS by reference. > > void incr(int &x) { > x++; > } > > int main(void) { > int b = 2; > incr(b); > cout << b << endl; > } > > in C++ (a) uses pass by reference, and (b) prints 3. > You cannot do that in Java. > > Java has pass by value and ONLY pass by value. > Some of those values are (perhaps confusingly) > called "object references" (in practice they are > almost always just plain pointers, something > Java is, again misleadingly, said not to have)., > > Correct. Remember Java came from C++, and in the early days most people expressing interest in Java were C++ programmers. The "no pointers" phrasing was meant to emphasize the fact that Java's pointers were opaque, not constructible and you could not perform arithmetic on them. Relatedly when I first read about Refs in Erlang, I assumed they were similar to the ones in ML or Haskell, that is, immutable references to mutable data elements. That took correcting. dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Mon May 23 04:33:02 2011 From: ok@REDACTED (Richard O'Keefe) Date: Mon, 23 May 2011 14:33:02 +1200 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: <661C1ED1-0683-435C-8BF0-5EAB2289D546@erlang-solutions.com> <73FD1684-4D13-40E1-8CE6-7CFE266AB382@cs.otago.ac.nz> Message-ID: On 21/05/2011, at 2:30 AM, Michael Turner wrote: > "... because THAT IS COVERED IN THE REFERENCE MANUAL WHERE THE VERY > FIRST THING AFTER THE SECTION HEADING SHOWS A MULTICLAUSE FUN." > > And (he says, ears ringing slightly) that somehow makes it OK for any other part of the documentation to be wrong, I did not say that. I did not say anything from which any reasonable person could infer that. For one thing, I do not accept that the other part of the documentation is WRONG, only that it is INCOMPLETE. And yes, provided the reference manual is complete, it IS ok for other documentation to be incomplete. > even when your average learner is far more likely to encounter the erroneous passage first? Only a very dumb and irresponsible learner would fail to check the reference manual. Yes, you read the tutorials, you try the examples. But when you want to know the details of something, you read the reference manual. IF you are competent at programming language learning. > Thanks for the update about the proportions of time spent scanning vs. parsing. I'm under the influence of something I heard Bill Joy (then a student of Sue Graham's) say about lex and yacc back around 1980 or so. In any case, can we at least agree that the change I suggest is going to have minimal impact on parsing times? Sure. I don't actually _care_ about parsing times. I care about the pain *I* would suffer if I had to read stuff written that way. > > "If both the existing readable alternative and the proposed horrible one are supported, the code *has* to increase in volume, and *has* to become less maintainable." > > Even if it actually reduces the number of grammar rules, There is no reason to believe that it would do anything of the kind. > or keeps the number the same, There is no reason to believe that it would do anything of the kind. > and even if it means the same amount of head-match checking we have now? I don't know what you mean here. I am not discussing run-time complexity but the source code. > > "You are attacking one of the features of Erlang that I have found most helpful." > > I found this "feature" helpful in a way myself: from doing some Prolog programming, I had some experience with writing code in this pattern. But when I was doing Prolog programming, I had the same complaint about Prolog: dreary repetition of redundant identifiers where whitespace and indentation would (I thought) enhance readability. It took some getting used to. But I suppose I could have learned to love it if I'd done more Prolog programming. > > We have an eye of the beholder problem, here, obviously. Compared with something like Haskell, Prolog can indeed be "drearily repetitive". But the predicate names are NOT the dreary or noticeably repetitive part. For what it's worth, the identifiers are *NOT* redundant in Prolog. (Amongst other things, have you forgotten the existence of assertz/1? Or the :- discontiguous declaration?) From dan@REDACTED Mon May 23 05:16:00 2011 From: dan@REDACTED (Daniel Dormont) Date: Sun, 22 May 2011 23:16:00 -0400 Subject: [erlang-questions] AST record syntax improvement In-Reply-To: <869690838.208511306103161268.JavaMail.root@zimbra> References: <1801378050.208491306103137344.JavaMail.root@zimbra> <869690838.208511306103161268.JavaMail.root@zimbra> Message-ID: On Sun, May 22, 2011 at 6:26 PM, Robert Virding < robert.virding@REDACTED> wrote: > I think the actual syntax is the least of your problems. The existing > syntax looks like it does much because of the properties of erlang and of > records. Records were added to give named fields to tuples and to be at > least as fast as directly using the tuple operations. This means that > everything had to be done at compile-time. And as erlang is dynamically > typed without any typed declarations then all type information has to be > given at each record operation. > > Recless tried to be smart and get around this and only require the field > names and not the record names. There are really only two ways of doing this > properly: > > 1. Require that all field names are unique in all records. > 2. Require some typing "help" so the system can work out which record types > are being accessed. > > I'm not sure why I have Haskell so much on my mind these days, but anyway: #1 is precisely what Haskell does. In addition, as shown in my example below, field names live in the same namespace as variables. It is not my favorite feature in that language. > The first is very difficult to work with in any large project. It would > even be difficult for all OTP records. The second would mean requiring > static type declarations to work properly and in all situations, which would > be a fundamental change to the current Erlang language. It would, in fact, > be a new language. > > Another thing to be aware of is that pattern matching and '=' complicate > the syntax. I personally don't think that > > NewProject = Project.owner.address.city = "Boston". > > is that much more intelligible. > > Just for fun, in Haskell this currently looks like: newProject = project { owner = (owner project) { address = (address (owner project)) { city = "Boston" }}} Not pretty. Then again, is it common to need to do nested updates of fields like that? dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Mon May 23 05:18:35 2011 From: ok@REDACTED (Richard O'Keefe) Date: Mon, 23 May 2011 15:18:35 +1200 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: Message-ID: <53AC4243-603E-4989-954F-6B512ACE102F@cs.otago.ac.nz> On 20/05/2011, at 1:43 AM, Michael Turner wrote: > The other parts of your argument relate to a problem shared with *every* language whose syntax has ever changed -- and that's all of them, except some dead ones perhaps. Should you try to be backward compatible with every release of every implementation of every language? Then languages wouldn't ever evolve. Is that such a good state of affairs? > > As for the befuddled newbie who runs smack into code not described in any book, Once again, it *is* described in the reference manual. That *has* to count as one of the relevant books. > supposedly becoming "*incredibly* confused ", that's pretty much a non-issue in this case Only so long as no code in the proposed style exists! > the simple reason that, for its intended purpose, the syntax I propose is transparently obvious, No, it is *NOT* transparently obvious. > at least if indented the way I propose (but that people here keep ignoring for some reason.) I don't think anyone has been ignoring it. Other people have criticised your proposed indentation, and I for one have proposed an alternative which is marginally less hostile to readers. I have seen this kind of syntax before in extensions to Scheme. It was NOT transparently obvious there, and it is not transparently here. There is, quite frankly, no such thing as "transparently obvious here. It's like what Ponder Stibbons says to the Archchancellor in "Hogfather" about the thinking engine, Hex: it's perfectly intuitive. You just have to spend six months learning it first. As it happens, I've written and tried to read enough code in this style to say that the "clueless" (as in, "it does not offer the reader any clue other than indentation") style *never* became "transparently obvious to me. Right now, there is a way to get very very nearly the style you want, with no language change whatever. Write foobar(_1, _2, _3) -> fun (....) -> ...; (....) -> ...; (....) -> ... end(_1, _2, _3). Done this way, the syntax for normal functions would not merely be _like_, it would actually _include_ the syntax for "funs" precisely. I note that ML also admits this possibility. Instead of fun f (_:_) = ... | f () = ... you *can* write val f = fn (_:_) -> ... | [] -> ... with no repeated name. Absolutely NO ML code that I've ever seen does it that way. Given absolute freedom to write functions the Erlang way or your way, ML programmers do not choose your way. I wonder why? From ok@REDACTED Mon May 23 05:32:47 2011 From: ok@REDACTED (Richard O'Keefe) Date: Mon, 23 May 2011 15:32:47 +1200 Subject: [erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions In-Reply-To: References: <661C1ED1-0683-435C-8BF0-5EAB2289D546@erlang-solutions.com> <3E70F4ECA6ED459C936583EE3B7301EC@srstrong.com> Message-ID: <9CCE52F2-62FC-41EE-A5A8-A94D2C5786A9@cs.otago.ac.nz> On 21/05/2011, at 5:51 AM, Michael Turner wrote: > > Here's the core paragraph from that first post: > > "It's also less to type and to read, which is consistent with the DRY principle ("Don't Repeat Yourself"). What you have failed to acknowledge is that DRY is a principle for *writers*, not a principle that is even intended to help *readers*. Readers benefit from having the information they need where they need it, when they need it. And that means redundancy. When you are writing to be read, REPETITION HELPS. > That's an argument in which readability weighs slightly more, isn't it? It's an argument in which readability is *mentioned* but in which it actually counts for nothing at all, in which nothing that is known to make anything more readable is suggested or even approved (other than good indentation, which you *did* take care over, but we all agree that good indentation is important even if we do not agree what it is). From the Wikipedia page about DRY: Kent Beck has mentioned that he does not "subscribe to [DRY] for test code because [he] want[s] [his] tests to read like a story".[2] He is implicitly saying that DRY harms readability. I should also point out that DRY simply isn't about source syntax. It's much more about architecture. Also, DRY is about there being a single authoritative source for some piece of knowledge. It is NOT about what is *displayed* to the programmer in an editing environment. Again, the needs of the reader and the needs of the writer are different. If Erlang had started with the syntax you recommend, by now we would have IDE tools to turn max (X, Y) when X >= Y -> X; (X, Y) -> Y. into max (X, Y) when X >= Y -> X; %max (X, Y) -> Y. providing the reader with a usefully redundant display. This would NOT violate the DRY principle. I've seen manually inserted comments of this kind in enough Lisp code... DRY is closely related to "Once and only once", and at the c2.com wiki page on that topic we find OnceAndOnlyOnce sounds like a nice principle but, when taken at face value, would lead to untested code. Even XP advocates stating each fact at least twice, preferably three times. From watson.timothy@REDACTED Mon May 23 11:21:39 2011 From: watson.timothy@REDACTED (Tim Watson) Date: Mon, 23 May 2011 10:21:39 +0100 Subject: [erlang-questions] Mocking I/O calls - defining sequence of returns In-Reply-To: References: <312F7919-F0D3-4BDB-AA0F-73951D42209A@gmail.com> Message-ID: > On May 22, 2011 2:40 AM, "Alyssa Kwan" wrote: >> I'm sorry, I wasn't being specific. Is there any way to mock a sequence of >> calls to the same function? Like if I call io:get_line (or a wrapper because >> it's protected), how do I get it to return a different value for the first >> call and the second call? >> >> Also, will it expect exactly two calls as well? And does meck record call >> order for different functions? I believe that meck preserves the call order and there is an API call to get back the call "history" as well - meck:history(Mod). As Tobias has pointed out, erlymock will do this for you too. If you're interested in tracking complex state in, say, a gen_server, there is also https://github.com/noss/emock which can be combined with other libraries to good effect. I'd also suggest looking at the statem functionality in either QuickCheck (http://www.quviq.com/) or https://github.com/manopapad/proper for complex cases. All of these can be combined with convenience libraries like https://github.com/hyperthunk/hamcrest-erlang if you want to sprinkle a little sugar on your test code! Here's a (somewhat contrived) example of what you want to do with meck: t4@REDACTED:~ $ erl Erlang R14B01 (erts-5.8.2) [source] [64-bit] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.8.2 (abort with ^G) 1> code:unstick_mod(io). true 2> meck:new(io, [passthrough]). ok 3> meck:expect(io, get_line, 1, "hello world!"). ok 4> io:get_line(prompt). "hello world!" 5> 5> meck:expect(io, get_line, 5> fun(name) -> "Joe Bloggs"; 5> (Other) -> meck:passthrough([Other]) 5> end). ok 6> io:get_line(name). "Joe Bloggs" 7> io:get_line(other). other "\n" 8> meck:unload(io). ok 9> meck:new(io, [passthrough]). ok 10> meck:expect(io, format, 2, "always return this"). ok 11> io:format("123 ~p~n", [hello]). "always return this" 12> io:format("123 ~p~n", [world]). "always return this" 13> WasPassedToIO = fun(X) -> lists:keymember({io, format, X}, 1, meck:history(io)) end. #Fun 14> hamcrest:assert_that(["123 ~p~n",[hello]], WasPassedToIO, fun() -> meck:unload(io) end). true 15> Or in a test module: -module(mytests). -include_lib("hamcrest/include/hamcrest.hrl"). passed_to_io() -> fun(X) -> lists:keymember({io, format, X}, 1, meck:history(io)) end. mytest() -> %% setup code, e.g., meck:new(....), meck:expect(...) ,etc ?assertThat(["123 ~p~n",[hello]], passed_to_io()). From demeshchuk@REDACTED Mon May 23 11:51:10 2011 From: demeshchuk@REDACTED (Dmitry Demeshchuk) Date: Mon, 23 May 2011 13:51:10 +0400 Subject: [erlang-questions] Mocking I/O calls - defining sequence of returns In-Reply-To: <312F7919-F0D3-4BDB-AA0F-73951D42209A@gmail.com> References: <312F7919-F0D3-4BDB-AA0F-73951D42209A@gmail.com> Message-ID: You can use meck and process dictionary combination, for example: mock_sequence(Mod, Fun, L) -> put({Mod, Fun}, L), meck:expect(Mod, Fun, fun() -> [H | T] = get({Mod, Fun}), put({Mod, Fun}, T), H end). On Sat, May 21, 2011 at 9:31 PM, Alyssa Kwan wrote: > Hi everyone! > > Are there any mocking libraries written that allow you to expect a sequence of calls and return a different value for each call? ?A mocking library that allows passthrough would be ideal. > > Thanks! > Alyssa > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Best regards, Dmitry Demeshchuk From watson.timothy@REDACTED Mon May 23 12:07:51 2011 From: watson.timothy@REDACTED (Tim Watson) Date: Mon, 23 May 2011 11:07:51 +0100 Subject: [erlang-questions] Mocking I/O calls - defining sequence of returns In-Reply-To: References: <312F7919-F0D3-4BDB-AA0F-73951D42209A@gmail.com> Message-ID: On 23 May 2011 10:51, Dmitry Demeshchuk wrote: > You can use meck and process dictionary combination, for example: That's a bit dangerous if the module under test gets called from multiple processes though, which is often (perhaps even normally?) the case. For very simple cases it might be ok though, as you say. From ulf.wiger@REDACTED Mon May 23 12:42:49 2011 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Mon, 23 May 2011 12:42:49 +0200 Subject: [erlang-questions] read_/write_concurrency ets table info Message-ID: <13BC1C2C-D4A4-4265-B6B8-F50A3E2A674F@erlang-solutions.com> Am I right in concluding that there is no way to check the read_concurrency and write_concurrency setting of an ets table? 7> T = ets:new(t, [{write_concurrency,true}]). 20497 8> ets:info(T, write_concurrency). ** exception error: bad argument in function ets:info/2 called as ets:info(20497,write_concurrency) BR, Ulf W Ulf Wiger, CTO, Erlang Solutions, Ltd. http://erlang-solutions.com From gustav.simonsson@REDACTED Mon May 23 12:45:14 2011 From: gustav.simonsson@REDACTED (Gustav Simonsson) Date: Mon, 23 May 2011 10:45:14 +0000 (GMT) Subject: [erlang-questions] Mocking I/O calls - defining sequence of returns In-Reply-To: <1000539005.210371306147424922.JavaMail.root@zimbra> Message-ID: <223343941.210391306147514241.JavaMail.root@zimbra> If using meck, you can solve that problem a few different ways depending on the context: if you have control between the different calls (in a test-scenario of a FSM for example) to your mocked function, you can simply define a new mocking behaviour for that function between the calls (with meck:passthrough/1 if you want the original function to be called). In the case where you do not have that control, you have to write the mocked fun() sent to meck:expect/3/4 to return different values for different arguments. In a scenario where you do not have control between the calls, and you send exactly the same arguments to the function several times but want it to behave differently, you can make use of meck:history/1 as in the examples Tim Watson presented earlier in this thread. Regards, Gustav Simonsson ----- Original Message ----- From: "Alyssa Kwan" To: "Edward Wang" Cc: erlang-questions@REDACTED Sent: Saturday, May 21, 2011 8:40:30 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: [erlang-questions] Mocking I/O calls - defining sequence of returns I'm sorry, I wasn't being specific. Is there any way to mock a sequence of calls to the same function? Like if I call io:get_line (or a wrapper because it's protected), how do I get it to return a different value for the first call and the second call? Also, will it expect exactly two calls as well? And does meck record call order for different functions? On May 21, 2011, at 1:43 PM, Edward Wang wrote: Try meck https://github.com/eproxus/meck I used it to mock inet:getifaddrs/0 etc. On Sun, May 22, 2011 at 1:31 AM, Alyssa Kwan < alyssa.c.kwan@REDACTED > wrote: Hi everyone! Are there any mocking libraries written that allow you to expect a sequence of calls and return a different value for each call? A mocking library that allows passthrough would be ideal. Thanks! Alyssa _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions From muhammad.yousaf@REDACTED Mon May 23 13:00:32 2011 From: muhammad.yousaf@REDACTED (Muhammad Yousaf) Date: Mon, 23 May 2011 17:00:32 +0600 Subject: [erlang-questions] Tool for performace evaluation Message-ID: Hi, Is there any tools to evaluate the performance of a module in Erlang that can show graphical interface for time elapse, memory usage, performance benchmarks etc ?? or is there any alternative to do this in Erlang Thanks in advance Regards, Muhammad Yousaf -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Mon May 23 13:31:54 2011 From: erlang@REDACTED (Joe Armstrong) Date: Mon, 23 May 2011 13:31:54 +0200 Subject: [erlang-questions] Erlang history In-Reply-To: <220785688.208311306100708694.JavaMail.root@zimbra> References: <2106282401.208291306100638006.JavaMail.root@zimbra> <220785688.208311306100708694.JavaMail.root@zimbra> Message-ID: I got it wrong it was NU not MU - we wrote a paper about this in 1992 it's at http://www.sics.se/~joe/pubs/prac_appl_prolog.ps "Use of prolog for developing a new programming language." J. L. Armstrong, S. R. Virding and M. C. Williams The Practical Application of Prolog" London 1 -- 3 april 1992 Section 2.6 paragraph 4 says: " The first version was a NU Prolog running on a VAX 11/750. It was then ported to Quintus Prolog on the same machine ... it was also ported to ALS Prolog runing on PC/AT's. We then Ported to SICSTUS and changed from the VAX 11/750 to SUBN 3/&0's and then to SICSTUS running on SPARC's. " So NU prolog was first was first. The order was NU -> Quintus -> SICSTUS I don't remember ALS having a s-expression syntax - I thought it was "edinburgh" standard? /Joe 2011/5/22 Robert Virding > Are you sure? I remember mu-prolog but I can't remember using it. > > Also ALS prolog which in the old days had a different more s-expr based > syntax. > > Robert > > > ----- "Joe Armstrong" wrote: > > Sicstus came later - first was mu prolog from Melborne. > > ( I don't thing sicstus was released in 1986) - I think we then > > bought quintus prolog - mu prolog only did GC on backtracking. > > We also bought the first every licence for ALS prolog so we could > > run on a PC > > > > /Joe > > > > > > > > > > On Sat, May 21, 2011 at 8:45 PM, Robert Virding < > robert.virding@REDACTED> wrote: > > > >> Hi I?aki, >> > >> > From what I can remember it was most likely sicstus prolog. Though it >> was a long time ago. >> > >> > Robert >> > >> > >> > ----- "I?aki Garay" wrote: >> > >> > > Good day Joe, Robert, >> > > >> > > not that it matters, but do you recall which Prolog implementation you >> > > used for the original Erlang compiler? >> > > I've read your paper "Use of Prolog for developing a new programming >> > > language" from '92, and recall a recorded talk you gave regarding >> > > Erlang internals in which you mentioned some historical facts, but >> > > could not find this tidbit. >> > > >> > > kind regards, >> > > I?aki Garay. >> > > _______________________________________________ >> > > erlang-questions mailing list >> > > erlang-questions@REDACTED >> > > http://erlang.org/mailman/listinfo/erlang-questions >> > _______________________________________________ >> > erlang-questions mailing list >> > erlang-questions@REDACTED >> > http://erlang.org/mailman/listinfo/erlang-questions >> > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From olopierpa@REDACTED Mon May 23 13:59:28 2011 From: olopierpa@REDACTED (Pierpaolo Bernardi) Date: Mon, 23 May 2011 13:59:28 +0200 Subject: [erlang-questions] Erlang history In-Reply-To: References: <2106282401.208291306100638006.JavaMail.root@zimbra> <220785688.208311306100708694.JavaMail.root@zimbra> Message-ID: On Mon, May 23, 2011 at 13:31, Joe Armstrong wrote: > I don't remember ALS having a s-expression syntax - I thought it was > "edinburgh" standard? As far as I remember, ALS always had Edinburgh syntax. It was micro-prolog that had the lispish syntax. P. From gustav.simonsson@REDACTED Mon May 23 14:26:57 2011 From: gustav.simonsson@REDACTED (Gustav Simonsson) Date: Mon, 23 May 2011 12:26:57 +0000 (GMT) Subject: [erlang-questions] Tool for performace evaluation In-Reply-To: Message-ID: <315503444.211231306153617444.JavaMail.root@zimbra> etop:start(). gives information similar to 'top' in UNIX: http://www.erlang.org/doc/man/etop.html Regards, Gustav Simonsson ----- Original Message ----- From: "Muhammad Yousaf" To: erlang-questions@REDACTED Sent: Monday, May 23, 2011 1:00:32 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: [erlang-questions] Tool for performace evaluation Hi, Is there any tools to evaluate the performance of a module in Erlang that can show graphical interface for time elapse, memory usage, performance benchmarks etc ?? or is there any alternative to do this in Erlang Thanks in advance Regards, Muhammad Yousaf _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions From spawn.think@REDACTED Mon May 23 14:49:16 2011 From: spawn.think@REDACTED (Ahmed Omar) Date: Mon, 23 May 2011 14:49:16 +0200 Subject: [erlang-questions] Tool for performace evaluation In-Reply-To: <315503444.211231306153617444.JavaMail.root@zimbra> References: <315503444.211231306153617444.JavaMail.root@zimbra> Message-ID: Your question sounds too vague :) but quick hints : 1) Monitoring tools : etop http://www.erlang.org/doc/man/etop.html ntop https://github.com/esl/entop 2) Profiling guide http://www.erlang.org/doc/efficiency_guide/profiling.html 3) Concurrency profiling tool http://www.erlang.org/doc/apps/percept/percept_ug.html On Mon, May 23, 2011 at 2:26 PM, Gustav Simonsson < gustav.simonsson@REDACTED> wrote: > > etop:start(). > > gives information similar to 'top' in UNIX: > http://www.erlang.org/doc/man/etop.html > > Regards, > Gustav Simonsson > > ----- Original Message ----- > From: "Muhammad Yousaf" > To: erlang-questions@REDACTED > Sent: Monday, May 23, 2011 1:00:32 PM GMT +01:00 Amsterdam / Berlin / Bern > / Rome / Stockholm / Vienna > Subject: [erlang-questions] Tool for performace evaluation > > > Hi, > > Is there any tools to evaluate the performance of a module in Erlang that > can show graphical interface for time elapse, memory usage, performance > benchmarks etc ?? > > or is there any alternative to do this in Erlang > > Thanks in advance > > Regards, > > > Muhammad Yousaf > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think -------------- next part -------------- An HTML attachment was scrubbed... URL: From sverker@REDACTED Mon May 23 14:57:44 2011 From: sverker@REDACTED (Sverker Eriksson) Date: Mon, 23 May 2011 14:57:44 +0200 Subject: [erlang-questions] read_/write_concurrency ets table info In-Reply-To: <13BC1C2C-D4A4-4265-B6B8-F50A3E2A674F@erlang-solutions.com> References: <13BC1C2C-D4A4-4265-B6B8-F50A3E2A674F@erlang-solutions.com> Message-ID: <4DDA59C8.9080808@erix.ericsson.se> Ulf Wiger wrote: > Am I right in concluding that there is no way to check the read_concurrency and write_concurrency setting of an ets table? > > Correct. > 7> T = ets:new(t, [{write_concurrency,true}]). > 20497 > 8> ets:info(T, write_concurrency). > ** exception error: bad argument > in function ets:info/2 > called as ets:info(20497,write_concurrency) > > If working, what would you expect from "ets:info(T, write_concurrency)" for tables that ignore the option ('private' and 'ordered_set' in current implementation)? /Sverker, Erlang/OTP From james.hague@REDACTED Mon May 23 16:02:48 2011 From: james.hague@REDACTED (James Hague) Date: Mon, 23 May 2011 09:02:48 -0500 Subject: [erlang-questions] memory allocation and constant pool behavior In-Reply-To: References: Message-ID: The only memory allocation done at runtime in your function is for a single two-element tuple containing pointers to existing tuples. It's the per tuple overhead + 2 words. According to the efficiency guide, tuple overhead is 2 words, giving a total of 4. (I had previously thought that the tuple overhead was 1 word, but the efficiency guide claims it to be 2. Did that change at some point or have I always been mistaken?) From phiroc@REDACTED Mon May 23 16:12:12 2011 From: phiroc@REDACTED (phiroc@REDACTED) Date: Mon, 23 May 2011 16:12:12 +0200 (CEST) Subject: [erlang-questions] Running an erl program on a remote machine In-Reply-To: <775754.2426841306159825826.JavaMail.root@spooler3-g27.priv.proxad.net> Message-ID: <10568124.2427131306159932568.JavaMail.root@spooler3-g27.priv.proxad.net> Hello, is it possible to run an erlang program on a remote machine without using the erl console? For instance, let's say that I have written a program that runs a batch script and that I would like to run it on machine B at a set time. Can I create an entry in my machine's crontab which runs the following script: erl -name machineB -detached Furthermore, how does Erlang create processes on remote machines? Does is use certificates? What must you do security-wise to allow process creation? Many thanks. Philippe From carlo.bertoldi@REDACTED Mon May 23 16:20:24 2011 From: carlo.bertoldi@REDACTED (Carlo Bertoldi) Date: Mon, 23 May 2011 16:20:24 +0200 Subject: [erlang-questions] Running an erl program on a remote machine In-Reply-To: <10568124.2427131306159932568.JavaMail.root@spooler3-g27.priv.proxad.net> References: <10568124.2427131306159932568.JavaMail.root@spooler3-g27.priv.proxad.net> Message-ID: <4DDA6D28.9020602@ubiquity.it> On 23/05/2011 16:12, phiroc@REDACTED wrote: > Hello, > > is it possible to run an erlang program on a remote machine without using the erl console? > > For instance, let's say that I have written a program that runs a batch script and that I would like to run it on machine B at a set time. Can I create an entry in my machine's crontab which runs the following script: > > erl -name machineB -detached > Why would you want to do that? Why not put that command directly in B's crontab? Carlo From attila.r.nohl@REDACTED Mon May 23 16:29:21 2011 From: attila.r.nohl@REDACTED (Attila Rajmund Nohl) Date: Mon, 23 May 2011 16:29:21 +0200 Subject: [erlang-questions] Running an erl program on a remote machine In-Reply-To: <10568124.2427131306159932568.JavaMail.root@spooler3-g27.priv.proxad.net> References: <775754.2426841306159825826.JavaMail.root@spooler3-g27.priv.proxad.net> <10568124.2427131306159932568.JavaMail.root@spooler3-g27.priv.proxad.net> Message-ID: 2011/5/23, phiroc@REDACTED : > Hello, > > is it possible to run an erlang program on a remote machine without using > the erl console? > > For instance, let's say that I have written a program that runs a batch > script and that I would like to run it on machine B at a set time. Can I > create an entry in my machine's crontab which runs the following script: > > erl -name machineB -detached script> You have to start the Erlang VM on the remote server somehow, possibly using ssh. Then it's just an other node. From raimo+erlang-questions@REDACTED Mon May 23 16:39:54 2011 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Mon, 23 May 2011 16:39:54 +0200 Subject: [erlang-questions] memory allocation and constant pool behavior In-Reply-To: References: Message-ID: <20110523143954.GA21561@erix.ericsson.se> On Mon, May 23, 2011 at 09:02:48AM -0500, James Hague wrote: > The only memory allocation done at runtime in your function is for a > single two-element tuple containing pointers to existing tuples. It's > the per tuple overhead + 2 words. According to the efficiency guide, > tuple overhead is 2 words, giving a total of 4. > > (I had previously thought that the tuple overhead was 1 word, but the > efficiency guide claims it to be 2. Did that change at some point or > have I always been mistaken?) Yes. Yes. No. (In that order) If you compare with e.g String you see it is annotated as 1 word + 2 words per element, and as we know it is one 2-word cons cell per character. The first mentioned 1 word is the handle to the list itself, either on the stack or on the heap in some other element. So the heap overhead for a tuple is 1 word, but there is a handle to the tuple somewhere too. For example: f({{1,2,3}}) causes one word on the stack that points to the outer 1-tuple on the heap where it occupies 2 words; the arity and one handle for the inner 3-tuple that occupies 4 heap words - total 7. You can view this as 2+3 caused by the inner tuple (Overhead+Payload) and 2+InnerTuple in the outer tuple (also Overhead+Payload). > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From phiroc@REDACTED Mon May 23 16:55:42 2011 From: phiroc@REDACTED (phiroc@REDACTED) Date: Mon, 23 May 2011 16:55:42 +0200 (CEST) Subject: [erlang-questions] Running an erl program on a remote machine In-Reply-To: <2943760.2435381306162354145.JavaMail.root@spooler3-g27.priv.proxad.net> Message-ID: <30753908.2435881306162542010.JavaMail.root@spooler3-g27.priv.proxad.net> Hi, I have been asked to write a script which runs database commands on one of n mirror machines. The name of the machine the commands should be run on is contained in a DNS alias called, say, THE_CURRENT_MACHINE. In other words, if the THE_CURRENT_MACHINE alias resolves to machineA.company.com, then the script should be run on that machine, if it resolves to machineB.company.com, it should run on machine b, etc. I have thought of several ways of doing the above: - run a PERL script at a set time each day on a machine which I will call machinex, which resolves the THE_CURRENT_MACHINE alias, connects to it via SSH and runs the database commands. The disadvantage of this solution is that, if machinex is down, the PERL script won't be run. - run a PERL script at a set time each day on machines A and B (and C and D...) makes sure that the current machine's name is equal to THE_CURRENT_MACHINE value, and, if that is the case, runs the database commands. The disadvantage of this solution is that if I have 10 machines, I must duplicate the script on those ten machines. - write an Erlang program which create a remote process on THE_CURRENT_MACHINE that runs the database commands, if it is feasible. Once again, if machinex is down, the program won't be run. - write an Erlang script which will run as a daemon on machines A, B, C... which checks every second if the time matches the time at which the database commands should be triggered, and, if that is the case, run them. If I had never heard of Erlang and of its alleged "spawn a remote process" capabilities, I would opt for solution 2 above. If you fellows have a better solution, please let me know. Philippe ----- Mail Original ----- De: "Carlo Bertoldi" ?: erlang-questions@REDACTED Envoy?: Lundi 23 Mai 2011 16:20:24 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: Re: [erlang-questions] Running an erl program on a remote machine On 23/05/2011 16:12, phiroc@REDACTED wrote: > Hello, > > is it possible to run an erlang program on a remote machine without using the erl console? > > For instance, let's say that I have written a program that runs a batch script and that I would like to run it on machine B at a set time. Can I create an entry in my machine's crontab which runs the following script: > > erl -name machineB -detached > Why would you want to do that? Why not put that command directly in B's crontab? Carlo _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions From carlo.bertoldi@REDACTED Mon May 23 17:01:35 2011 From: carlo.bertoldi@REDACTED (Carlo Bertoldi) Date: Mon, 23 May 2011 17:01:35 +0200 Subject: [erlang-questions] Running an erl program on a remote machine In-Reply-To: <2943760.2435381306162354145.JavaMail.root@spooler3-g27.priv.proxad.net> References: <2943760.2435381306162354145.JavaMail.root@spooler3-g27.priv.proxad.net> Message-ID: <4DDA76CF.6070304@ubiquity.it> On 23/05/2011 16:52, phiroc@REDACTED wrote: > Hi, > > I have been asked to write a script which runs database commands on one of n > mirror machines. The name of the machine the commands should be run on is > contained in a DNS alias called, say, THE_CURRENT_MACHINE. In other words, > if the THE_CURRENT_MACHINE alias resolves to machineA.company.com, > then the script should be run on that machine, if it resolves to > machineB.company.com, it should run on machine b, etc. snip > - write an Erlang script which will run as a daemon on machines A, B, C... > which checks every second if the time matches the time at which the database > commands should be triggered, and, if that is the case, run them. You can start an Erlang node on each machine, and run on it a simple process that waits for a start_your_db_ops. Then on one machine you could run the master process, that resolves the host and send the message to the appropriate node. Carlo From mlortiz@REDACTED Mon May 23 17:34:42 2011 From: mlortiz@REDACTED (Marcos Ortiz) Date: Mon, 23 May 2011 11:04:42 -0430 Subject: [erlang-questions] Erlang Development with Vim Message-ID: <4DDA7E92.3010704@uci.cu> Regards to all the list. Do you know any Vim plugin for Erlang Development? This is my primary editor and It would be nice to work on Erlang using it too. Thanks -- Marcos Lu?s Ort?z Valmaseda Software Engineer (Large-Scaled Distributed Systems) University of Information Sciences, La Habana, Cuba Linux User # 418229 http://about.me/marcosortiz From phiroc@REDACTED Mon May 23 17:13:24 2011 From: phiroc@REDACTED (phiroc@REDACTED) Date: Mon, 23 May 2011 17:13:24 +0200 (CEST) Subject: [erlang-questions] Running an erl program on a remote machine In-Reply-To: <4766856.2438671306163257755.JavaMail.root@spooler3-g27.priv.proxad.net> Message-ID: <32859648.2440591306163604314.JavaMail.root@spooler3-g27.priv.proxad.net> By "start an Erlang node on each machine" do you mean create a service which start an erl instance in detached mode, and that instance runs a program which creates a process that listens to the master machine? I don't want to keep n terminals open (one of the master machine erl, one for each of the slave machines, etc). Philippe ----- Mail Original ----- De: "Carlo Bertoldi" ?: "Erlang" Envoy?: Lundi 23 Mai 2011 17:01:35 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: Re: [erlang-questions] Running an erl program on a remote machine On 23/05/2011 16:52, phiroc@REDACTED wrote: > Hi, > > I have been asked to write a script which runs database commands on one of n > mirror machines. The name of the machine the commands should be run on is > contained in a DNS alias called, say, THE_CURRENT_MACHINE. In other words, > if the THE_CURRENT_MACHINE alias resolves to machineA.company.com, > then the script should be run on that machine, if it resolves to > machineB.company.com, it should run on machine b, etc. snip > - write an Erlang script which will run as a daemon on machines A, B, C... > which checks every second if the time matches the time at which the database > commands should be triggered, and, if that is the case, run them. You can start an Erlang node on each machine, and run on it a simple process that waits for a start_your_db_ops. Then on one machine you could run the master process, that resolves the host and send the message to the appropriate node. Carlo _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions From carlo.bertoldi@REDACTED Mon May 23 17:18:27 2011 From: carlo.bertoldi@REDACTED (Carlo Bertoldi) Date: Mon, 23 May 2011 17:18:27 +0200 Subject: [erlang-questions] Running an erl program on a remote machine In-Reply-To: <32859648.2440591306163604314.JavaMail.root@spooler3-g27.priv.proxad.net> References: <32859648.2440591306163604314.JavaMail.root@spooler3-g27.priv.proxad.net> Message-ID: <4DDA7AC3.3080009@ubiquity.it> On 23/05/2011 17:13, phiroc@REDACTED wrote: > By "start an Erlang node on each machine" do you mean create a service which start an erl instance in detached mode, and that instance runs a program which creates a process that listens to the master machine? > > I don't want to keep n terminals open (one of the master machine erl, one for each of the slave machines, etc). > > Philippe > Yes, more or less like you wrote in the first mail. Have a look at this tutorial to understand some of the problems related to remote nodes communication: http://www.ejabberd.im/interconnect-erl-nodes If something is not clear, blow a whistle ;) Carlo From kenneth.lundin@REDACTED Mon May 23 17:18:52 2011 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Mon, 23 May 2011 17:18:52 +0200 Subject: [erlang-questions] ASN.1 PER Does Not Correctly Handle Value Range Size Constraint In-Reply-To: <4DD813ED.6080509@gmail.com> References: <4DD813ED.6080509@gmail.com> Message-ID: Hi, You have spotted a weak point in the ASN.1 compiler but it is not the type of wrong behaviour as you think. For BIT STRING and SEQUENCE OF the standard defines that the following constraints are applicable: - Single value, - Contained Subtype - Size constraint But not Value-range On Sat, May 21, 2011 at 9:35 PM, Behdad Forghani wrote: > Hi, > > I have tested this on R14B02. > > I noticed that ASN.1 compiler does not handle value range size constraints > for SEQUENCE OF and BIT STRING. > > For example: > Abs ::= BIT STRING(0|1|7) I don't know how to interpret Abs, what does it mean? i.e. the 0|1|7 is it value 0, 1, 7? it is certainly not the size since then you have to write (SIZE(0|1|7)) > Bbs ::= BIT STRING(3..18) This is a value range which is clearly not applicable (the compiler should have rejected this) If you want a SIZE constraint you should write BIT STRING (SIZE(3..18)) > Cbs ::= BIT STRING > > > Abs has a size constraint of 0..7 and Bbs, 3..18. These are not size constraints they are value ranges. Which are not applicable. I have to check the standard regarding the union to see what it means for a BIT STRING if it is applicable at all. > > All three of the above will be encoded identically as length indeterminant > as 0x07DA. This is only correct for Cbs. The problem seems to be that > encode_bit_string calls get_constraint(C,'SizeConstraint'). > > However the constraint for the Abs is a UNION and for Bbs a ValueRange. It > seems to me the support for both constraints needs to be added. No I don't think so. I think it should be added functionality to reject constraints which are not applicable for the type in question. > > Just FYI, trying to give something back to the community. If I am correct, I > can easily fix it. In that case, can you enlighten me on how to submit my > code changes? > > Behdad > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > /Kenneth Erlang/OTP, Ericsson From banibrata.dutta@REDACTED Mon May 23 17:19:44 2011 From: banibrata.dutta@REDACTED (Banibrata Dutta) Date: Mon, 23 May 2011 20:49:44 +0530 Subject: [erlang-questions] Erlang Development with Vim In-Reply-To: <4DDA7E92.3010704@uci.cu> References: <4DDA7E92.3010704@uci.cu> Message-ID: On Mon, May 23, 2011 at 9:04 PM, Marcos Ortiz wrote: > Regards to all the list. > Do you know any Vim plugin for Erlang Development? > This is my primary editor and It would be nice to work on Erlang using it > too. > https://github.com/jimenezrick/vimerl ps> top few hits for "vim plugin erlang" on google have what you are looking for. -------------- next part -------------- An HTML attachment was scrubbed... URL: From watson.timothy@REDACTED Mon May 23 17:53:26 2011 From: watson.timothy@REDACTED (Tim Watson) Date: Mon, 23 May 2011 16:53:26 +0100 Subject: [erlang-questions] Erlang Development with Vim In-Reply-To: <4DDA7E92.3010704@uci.cu> References: <4DDA7E92.3010704@uci.cu> Message-ID: http://lmgtfy.com/?q=vim+plugin+erlang From mrtndimitrov@REDACTED Mon May 23 18:01:23 2011 From: mrtndimitrov@REDACTED (Martin Dimitrov) Date: Mon, 23 May 2011 19:01:23 +0300 Subject: [erlang-questions] Calling multiple processes simultaneously Message-ID: <4DDA84D3.4060400@gmail.com> Hi, please, advise on this one, We have several hundred processes (gen_servers) . At one point the program has to send them a message that needs to be handled before the calling process can continue executing. This naturally led us to use gen_server:call in loop over the processes. I started to wonder if there is a more efficient way of doing it since the calling process doesn?t care about the return value ? just needs to be sure that all processes had handled the message. Can we somehow call the processes simultaneously? Something similar to gen_server:multi_call but for one node with different processes? Regards, Martin From mihai@REDACTED Mon May 23 18:13:28 2011 From: mihai@REDACTED (Mihai Balea) Date: Mon, 23 May 2011 12:13:28 -0400 Subject: [erlang-questions] Calling multiple processes simultaneously In-Reply-To: <4DDA84D3.4060400@gmail.com> References: <4DDA84D3.4060400@gmail.com> Message-ID: On May 23, 2011, at 12:01 PM, Martin Dimitrov wrote: > Hi, please, advise on this one, > > We have several hundred processes (gen_servers) . At one point the > program has to send them a message that needs to be handled before the > calling process can continue executing. This naturally led us to use > gen_server:call in loop over the processes. > > I started to wonder if there is a more efficient way of doing it since > the calling process doesn?t care about the return value ? just needs to > be sure that all processes had handled the message. Can we somehow call > the processes simultaneously? Something similar to gen_server:multi_call > but for one node with different processes? You could do gen_server:cast in a loop, then wait for all servers to send a "message handled" response back to your main process. There's no built in way to do this, as far as I know, so you'll have to implement the cast and wait loops manually. Mihai From mrtndimitrov@REDACTED Mon May 23 18:15:10 2011 From: mrtndimitrov@REDACTED (Martin Dimitrov) Date: Mon, 23 May 2011 19:15:10 +0300 Subject: [erlang-questions] Calling multiple processes simultaneously In-Reply-To: References: <4DDA84D3.4060400@gmail.com> Message-ID: <4DDA880E.1060300@gmail.com> Thanks for the reply. We will be thinking in this direction. Martin On 5/23/2011 7:13 PM, Mihai Balea wrote: > On May 23, 2011, at 12:01 PM, Martin Dimitrov wrote: > >> Hi, please, advise on this one, >> >> We have several hundred processes (gen_servers) . At one point the >> program has to send them a message that needs to be handled before the >> calling process can continue executing. This naturally led us to use >> gen_server:call in loop over the processes. >> >> I started to wonder if there is a more efficient way of doing it since >> the calling process doesn?t care about the return value ? just needs to >> be sure that all processes had handled the message. Can we somehow call >> the processes simultaneously? Something similar to gen_server:multi_call >> but for one node with different processes? > > You could do gen_server:cast in a loop, then wait for all servers to send a "message handled" response back to your main process. > There's no built in way to do this, as far as I know, so you'll have to implement the cast and wait loops manually. > > Mihai From freza@REDACTED Mon May 23 18:26:36 2011 From: freza@REDACTED (Jachym Holecek) Date: Mon, 23 May 2011 17:26:36 +0100 Subject: [erlang-questions] Calling multiple processes simultaneously In-Reply-To: <4DDA84D3.4060400@gmail.com> References: <4DDA84D3.4060400@gmail.com> Message-ID: <20110523162636.GA6224@hanele> # Martin Dimitrov 2011-05-23: > We have several hundred processes (gen_servers) . At one point the > program has to send them a message that needs to be handled before the > calling process can continue executing. This naturally led us to use > gen_server:call in loop over the processes. > > I started to wonder if there is a more efficient way of doing it since > the calling process doesn?t care about the return value ? just needs to > be sure that all processes had handled the message. Can we somehow call > the processes simultaneously? Something similar to gen_server:multi_call > but for one node with different processes? You can steal the logic from gen_server:call/N and adapt it for your purpose -- basically: setup monitors on all servers, send $gen_call tagged request to all servers, run a loop receiving responses and DOWN messages, accumulate successes/failures and return both lists when done. Also demonitor all non-DOWN servers afterwards. That's just a sketch off the top of my head -- we have routines like that for multi-calls towards gen_servers and gen_fsms, IIRC they're all pretty simple (BTW the only difference between various flavours is the request tag -- all of the logic is the same), so you shouldn't have much trouble writing your own. BR, -- Jachym From james.hague@REDACTED Mon May 23 19:00:28 2011 From: james.hague@REDACTED (James Hague) Date: Mon, 23 May 2011 12:00:28 -0500 Subject: [erlang-questions] memory allocation and constant pool behavior In-Reply-To: <20110523143954.GA21561@erix.ericsson.se> References: <20110523143954.GA21561@erix.ericsson.se> Message-ID: > So the heap overhead for a tuple is 1 word, but there is a handle > to the tuple somewhere too. Thank you for the clarification! To me, it's simpler to say that a tuple has one word of overhead plus one word for each element. An element is either right there (in the case of small integers and atoms) or it's a pointer elsewhere. Getting back to the original posters question, the answer is that the function allocates 3 words: 1 for the tuple overhead, 2 for the elements. From james@REDACTED Mon May 23 19:18:32 2011 From: james@REDACTED (James Aimonetti) Date: Mon, 23 May 2011 10:18:32 -0700 Subject: [erlang-questions] Upcoming San Francisco ErLounge - Wed 25th @ Heroku Message-ID: <4DDA96E8.5090109@2600hz.com> The Heroku folks have offered to host an ErLounge at their offices Wednesday evening. We haven't been able to get in touch with the Meetup organizer, so I''m posting this here in hopes that folks will see it and we can get it added to the calendar. The offices are located at 321 11th St, San Francisco (near Folsom). Orion, if you want to provide more details for parking, buses, time, etc, that'd be great. Sorry for the short notice; hope to see folks there to learn about how Heroku uses Erlang and general Erlang discussion. I'll be bringing two others with me for sure, possibly a third. -- James Aimonetti Distributed Systems Engineer / DJ MC_ 2600hz | http://2600hz.com sip:james@REDACTED tel: 415.886.7905 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nem@REDACTED Mon May 23 19:28:35 2011 From: nem@REDACTED (Geoff Cant) Date: Mon, 23 May 2011 10:28:35 -0700 Subject: [erlang-questions] Upcoming San Francisco ErLounge - Wed 25th @ Heroku In-Reply-To: <4DDA96E8.5090109@2600hz.com> References: <4DDA96E8.5090109@2600hz.com> Message-ID: I'm in. Might even have an interesting (and shortish) lightning talk to give if R14B03 drops on Wednesday :) -Geoff On 2011-05-23, at 10:18 , James Aimonetti wrote: > The Heroku folks have offered to host an ErLounge at their offices Wednesday evening. > > We haven't been able to get in touch with the Meetup organizer, so I''m posting this here in hopes that folks will see it and we can get it added to the calendar. > > The offices are located at 321 11th St, San Francisco (near Folsom). Orion, if you want to provide more details for parking, buses, time, etc, that'd be great. > > Sorry for the short notice; hope to see folks there to learn about how Heroku uses Erlang and general Erlang discussion. > > I'll be bringing two others with me for sure, possibly a third. > > -- > James Aimonetti > Distributed Systems Engineer / DJ MC_ > > 2600hz | http://2600hz.com > sip:james@REDACTED > tel: 415.886.7905 > From alyssa.c.kwan@REDACTED Mon May 23 20:25:41 2011 From: alyssa.c.kwan@REDACTED (Alyssa Kwan) Date: Mon, 23 May 2011 14:25:41 -0400 Subject: [erlang-questions] Mocking I/O calls - defining sequence of returns In-Reply-To: References: Message-ID: Hi everyone! Thanks to everyone for all of your help! I'm writing a REPL for s-expressions, which I've implemented using io:get_line using the same arguments for every line. So unit testing called for returning a sequence of values for each call, which were identical. I was able to do what I want with meck using meck:history. FYI, the process dictionary solution doesn't work with meck because the fun passed in doesn't execute in the same process as the test process. I haven't had a chance to try Sven Heyll's erlymock, because I can't get maven-erlang-plugin to work on my box yet, but I think I'll be migrating to that once I do. I like the approach of explicitly declaring a mock object, which allows tracking of call order over multiple mocked modules. That's key for testing state-changing units which mocks are good for. Also, funs are supposedly executed in the test process, which allows for better error reporting in the console (I'm using rebar eunit). However, AFAIK, erlymock doesn't allow passthrough, which isn't nice. I'm going to try to work on extending that. Building in support for a sequence of returns would also be nice. Thanks! Alyssa From moxford@REDACTED Mon May 23 20:44:59 2011 From: moxford@REDACTED (Mike Oxford) Date: Mon, 23 May 2011 11:44:59 -0700 Subject: [erlang-questions] Erlang with Thrift Message-ID: Thrift's RPC mechanism is very one-way. Is anyone pipelining the Thift protocol over erlang sockets? I cannot seem to find any examples via Google. Thanks! -mox -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebegumisa@REDACTED Mon May 23 21:24:53 2011 From: ebegumisa@REDACTED (Edmond Begumisa) Date: Tue, 24 May 2011 05:24:53 +1000 Subject: [erlang-questions] QuickCheck/PropEr In-Reply-To: <319EB5973BAA42579692F3000F036E22@JohnsTablet2009> References: <319EB5973BAA42579692F3000F036E22@JohnsTablet2009> Message-ID: Thanks John, This was most helpful and got me over that initial hurdle. I see now that property-based testing is more about defining how the system should behave and is best used as a design-time aid -- almost like programming by contract. Write properties first, code from there. Thinking of it the other way had caused me great confusion. With some head-scratching, I can now (usually) retrospectively come up with properties for my libraries and codecs after watching this. But now I have a different problem! Libraries and codecs were at the bottom of my list for things I wanted to do automated tests on coz these don't fail much (time constrains mean I can ignore them for now). State machines and IPC are at the top. I know -- I'm jumping straight into the deep end. But I need to test the complex stuff in my apps rather than the simpler stuff! Knowing that these are features for the commercial version of QuickCheck, I'll direct the following silly questions to PropEr users instead: * proper_fsm now makes more sense (reminds me a little of UBF(C)). But I'm having trouble with defining properties for my gen_servers. From what I can tell, I need to somehow use {set, {var, _}, {call, _}} symbolic reps for the callbacks. Something I realised from watching ... http://www.quviq.com/demos/QuickCheck%20Elevator%20Demo/QuickCheck%20Elevator%20Demo.htm .. and from "Testing Stateful Code" in PropEr's README. But I can't figure out how to actually write the properties with symbolic reps for the callbacks. Can anyone offer me an example on how to do this? * If I want to test a group of modules/processes rather than just one. Specifically, a subtree in my supervision tree. How would I go about doing this? Using the elevator example: say elevator.erl spawns several people processes defined by person.erl. I write properties for both modules and test them individually. But if I want to then write properties that depend on actual interaction between elevator.erl and several person.erl processes, where would I start? Thanks in advance for any help. - Edmond - On Sun, 22 May 2011 20:20:06 +1000, John Hughes wrote: > Hi Edmond, > > You're not alone--there is a hurdle to get over, a different way of > thinking about testing. My talk at the last Erlang Factory in SF was > specifically intended to help people just starting out--the video and > slides are on the web at > http://www.erlang-factory.com/conference/SFBay2011/speakers/JohnHughes. > Be interested to hear if you find it helpful/not helpful. > > John > > > ----- Original Message ----- From: "Edmond Begumisa" > > To: > Sent: Sunday, May 22, 2011 12:01 AM > Subject: [erlang-questions] QuickCheck > > >> Hello all, >> >> I'm a QuickCheck noob trying out PropEr. Actually, I'm very embarrassed >> to admit that I'm very new to formal testing in general (I've always >> done things in the ad-hoc way for longer than I care to admit). I only >> confess to this coz I probably wouldn't get away with lying about it on >> *this* list when I start asking stupid questions! >> >> Anyways, I'm having A LOT of trouble getting started. The initial >> inertia just isn't there. Even with the available documentation from >> both QuviQ and PropEr. I look at my code and don't know where to begin >> writing tests for it! A sad state of affairs. >> >> I think I just need a few good tutorials. Can anyone recommend some >> QuickCheck resources to get me going that they've actually successfully >> used? Do I need to first start out with more "traditional" testing >> tools first before even attempting QuickCheck? >> >> Thanks in advance for you help. >> >> - Edmond - >> >> -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From mrtndimitrov@REDACTED Mon May 23 21:39:23 2011 From: mrtndimitrov@REDACTED (Martin Dimitrov) Date: Mon, 23 May 2011 22:39:23 +0300 Subject: [erlang-questions] Calling multiple processes simultaneously In-Reply-To: <20110523162636.GA6224@hanele> References: <4DDA84D3.4060400@gmail.com> <20110523162636.GA6224@hanele> Message-ID: <4DDAB7EB.6030205@gmail.com> > You can steal the logic from gen_server:call/N and adapt it for your > purpose -- basically: setup monitors on all servers, send $gen_call > tagged request to all servers, run a loop receiving responses and > DOWN messages, accumulate successes/failures and return both lists > when done. Also demonitor all non-DOWN servers afterwards. > Thanks for the reply but could you clarify the logic? What do you mean by DOWN messages? Regards, Martin From torben.lehoff@REDACTED Mon May 23 21:40:19 2011 From: torben.lehoff@REDACTED (Torben Hoffmann) Date: Mon, 23 May 2011 21:40:19 +0200 Subject: [erlang-questions] Calling multiple processes simultaneously In-Reply-To: <4DDA84D3.4060400@gmail.com> References: <4DDA84D3.4060400@gmail.com> Message-ID: Hi Martin, I would try to avoid overloading the protocol between the program and the gen_servers - instead I would introduce a gen_sync module that handles the synchronisation for you. The program would provide a list of {M,F,A}'s that all have to be synchronous calls in your gen_server modules. The gen_sync module would then spawn a process for each of the {M,F,A}'s and monitor them for successful completion. When all processes have returned - either successfully or failed - the gen_sync call would return with an appropriate answer. Exactly what is appropriate is up to you. Yes, this requires another module in your design, but you can re-use it elsewhere and it provides a nice abstraction for the multi-synchronisation by pushing all the synchronisation into the gen_sync module. gen_sync would be a gen_server as far as I can tell, unless you want to elaborate the functionality and have some states... not sure what those should be so it is probably overkill. Cheers, Torben On Mon, May 23, 2011 at 18:01, Martin Dimitrov wrote: > Hi, please, advise on this one, > > We have several hundred processes (gen_servers) . At one point the > program has to send them a message that needs to be handled before the > calling process can continue executing. This naturally led us to use > gen_server:call in loop over the processes. > > I started to wonder if there is a more efficient way of doing it since > the calling process doesn?t care about the return value ? just needs to > be sure that all processes had handled the message. Can we somehow call > the processes simultaneously? Something similar to gen_server:multi_call > but for one node with different processes? > > Regards, > > Martin > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- http://www.linkedin.com/in/torbenhoffmann -------------- next part -------------- An HTML attachment was scrubbed... URL: From yrashk@REDACTED Mon May 23 21:49:29 2011 From: yrashk@REDACTED (Yurii Rashkovskii) Date: Mon, 23 May 2011 12:49:29 -0700 (PDT) Subject: [erlang-questions] Upcoming San Francisco ErLounge - Wed 25th @ Heroku In-Reply-To: <4DDA96E8.5090109@2600hz.com> Message-ID: <14115486.11.1306180169947.JavaMail.geo-discussion-forums@prcm34> You can RSVP here: http://www.meetup.com/ErLounge/events/19410211/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nem@REDACTED Mon May 23 22:20:23 2011 From: nem@REDACTED (Geoff Cant) Date: Mon, 23 May 2011 13:20:23 -0700 Subject: [erlang-questions] Calling multiple processes simultaneously In-Reply-To: <4DDA84D3.4060400@gmail.com> (Martin Dimitrov's message of "Mon, 23 May 2011 19:01:23 +0300") References: <4DDA84D3.4060400@gmail.com> Message-ID: gen_server:call boils down to call(Server, Msg, Timeout) -> Ref = monitor(Server), % or make_ref() Server ! {'$gen_call$', {self(), Ref}, Msg}, receive {Ref, Reply} -> Reply {'DOWN', Ref, _, _, Reason} -> exit(Reason) after Timeout -> exit(timeout) end. If you do: barrier(Servers, Msg) -> [ gen_server:call(S, Msg) || S <- Servers ], ok. Then you'll wait at least Servers*2 message delays, and at worst Servers * the gen_server call default timeout (5s). You could do all the calls concurrently with something like: call(Servers, Msg, Timeout) -> Refs = [{S, monitor(S)}|| S <- Servers], [S ! {'$gen_call$', {self(), Ref}, Msg} || {S, Ref} <- Refs ], collect_replies(Refs, Timeout). collect_replies([], _) -> []; collect_replies([{S, Ref} | Rest], Timeout) -> receive {Ref, Reply} -> [{S, Reply} | collect_replies(Rest, Timeout)]; {'DOWN', Ref, _, _, Reason} -> [{S, {error, Reason}} | collect_replies(Rest, Timeout)] after Timeout -> %% Timeout is now expired for all servers. [{S, {error, timeout}} | collect_replies(Rest, 0)] end. This contains a basic attempt to not wait N*Timeout at worst, but could be made closer to 1 timeout max by measuring the time from entering collect_replies to receiving a Ref message and subtracting that from Timeout before recurring. This code doesn't handle all the special cases that gen:call does ( https://github.com/erlang/otp/blob/master/lib/stdlib/src/gen.erl#L191 ), but should illustrate the idea. -- Geoff Cant Martin Dimitrov writes: > Hi, please, advise on this one, > > We have several hundred processes (gen_servers) . At one point the > program has to send them a message that needs to be handled before the > calling process can continue executing. This naturally led us to use > gen_server:call in loop over the processes. > > I started to wonder if there is a more efficient way of doing it since > the calling process doesn?t care about the return value ? just needs to > be sure that all processes had handled the message. Can we somehow call > the processes simultaneously? Something similar to gen_server:multi_call > but for one node with different processes? > > Regards, > > Martin > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From ebegumisa@REDACTED Mon May 23 22:50:54 2011 From: ebegumisa@REDACTED (Edmond Begumisa) Date: Tue, 24 May 2011 06:50:54 +1000 Subject: [erlang-questions] Calling multiple processes simultaneously In-Reply-To: <4DDA84D3.4060400@gmail.com> References: <4DDA84D3.4060400@gmail.com> Message-ID: Another option... call_gen_servers(Pids) -> Ref = erlang:make_ref(), Caller = self(), lists:foreach(fun(P) -> spawn_link(fun() -> {reply, ok, _} = gen_server:call(foo, bar), Caller ! {self(), Ref} end). end, Pids), ok = wait_gen_servers(length(Pids), Ref). wait_gen_servers(0, _) -> ok; wait_gen_servers(N, Ref) -> receive {_, Ref} -> wait_gen_servers(N-1, Ref) end. You could also add the timeout. - Edmond - On Tue, 24 May 2011 02:01:23 +1000, Martin Dimitrov wrote: > Hi, please, advise on this one, > > We have several hundred processes (gen_servers) . At one point the > program has to send them a message that needs to be handled before the > calling process can continue executing. This naturally led us to use > gen_server:call in loop over the processes. > > I started to wonder if there is a more efficient way of doing it since > the calling process doesn?t care about the return value ? just needs to > be sure that all processes had handled the message. Can we somehow call > the processes simultaneously? Something similar to gen_server:multi_call > but for one node with different processes? > > Regards, > > Martin > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From ebegumisa@REDACTED Mon May 23 22:54:23 2011 From: ebegumisa@REDACTED (Edmond Begumisa) Date: Tue, 24 May 2011 06:54:23 +1000 Subject: [erlang-questions] Calling multiple processes simultaneously In-Reply-To: References: <4DDA84D3.4060400@gmail.com> Message-ID: Actually, {reply, ok, _} = gen_server:call(foo, bar), ...should be ... _ = gen_server:call(foo, bar), ... since you don't care about the reply, but just want a reply. - Edmond - On Tue, 24 May 2011 06:50:54 +1000, Edmond Begumisa wrote: > Another option... > > call_gen_servers(Pids) -> > Ref = erlang:make_ref(), > Caller = self(), > lists:foreach(fun(P) -> > spawn_link(fun() -> > {reply, ok, _} = > gen_server:call(foo, bar), > Caller ! {self(), Ref} > end). > end, Pids), > ok = wait_gen_servers(length(Pids), Ref). > > wait_gen_servers(0, _) -> > ok; > wait_gen_servers(N, Ref) -> > receive > {_, Ref} -> > wait_gen_servers(N-1, Ref) > end. > > You could also add the timeout. > > - Edmond - > > On Tue, 24 May 2011 02:01:23 +1000, Martin Dimitrov > wrote: > >> Hi, please, advise on this one, >> >> We have several hundred processes (gen_servers) . At one point the >> program has to send them a message that needs to be handled before the >> calling process can continue executing. This naturally led us to use >> gen_server:call in loop over the processes. >> >> I started to wonder if there is a more efficient way of doing it since >> the calling process doesn?t care about the return value ? just needs to >> be sure that all processes had handled the message. Can we somehow call >> the processes simultaneously? Something similar to gen_server:multi_call >> but for one node with different processes? >> >> Regards, >> >> Martin >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From ixmatus@REDACTED Mon May 23 23:41:50 2011 From: ixmatus@REDACTED (Parnell Springmeyer) Date: Mon, 23 May 2011 14:41:50 -0700 Subject: [erlang-questions] Running an erl program on a remote machine In-Reply-To: <30753908.2435881306162542010.JavaMail.root@spooler3-g27.priv.proxad.net> (phiroc@free.fr's message of "Mon, 23 May 2011 16:55:42 +0200 (CEST)") References: <30753908.2435881306162542010.JavaMail.root@spooler3-g27.priv.proxad.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Python + Fabric Erlang could be used, but honestly, it really isn't suited for that sort of thing - if you had to process a set of data across multiple nodes, then I would totally recommend Erlang; but Python + Fabric is just so /easy/ to run shell commands on remote machines! phiroc@REDACTED writes: > Hi, > > I have been asked to write a script which runs database commands on one of n > mirror machines. The name of the machine the commands should be run on is > contained in a DNS alias called, say, THE_CURRENT_MACHINE. In other words, > if the THE_CURRENT_MACHINE alias resolves to machineA.company.com, > then the script should be run on that machine, if it resolves to > machineB.company.com, it should run on machine b, etc. > > I have thought of several ways of doing the above: > > - run a PERL script at a set time each day on a machine which I will call > machinex, which resolves the THE_CURRENT_MACHINE alias, connects to > it via SSH and runs the database commands. The disadvantage of > this solution is that, if machinex is down, the PERL script won't be run. > > - run a PERL script at a set time each day on machines A and B (and C and D...) > makes sure that the current machine's name is equal to THE_CURRENT_MACHINE value, > and, if that is the case, runs the database commands. > The disadvantage of this solution is that if I have 10 machines, I > must duplicate the script on those ten machines. > > - write an Erlang program which create a remote process on THE_CURRENT_MACHINE that > runs the database commands, if it is feasible. Once again, if machinex is down, > the program won't be run. > > - write an Erlang script which will run as a daemon on machines A, B, C... > which checks every second if the time matches the time at which the database > commands should be triggered, and, if that is the case, run them. > > If I had never heard of Erlang and of its alleged "spawn a remote process" capabilities, > I would opt for solution 2 above. If you fellows have a better solution, please let me know. > > Philippe > > > > > ----- Mail Original ----- > De: "Carlo Bertoldi" > ?: erlang-questions@REDACTED > Envoy?: Lundi 23 Mai 2011 16:20:24 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne > Objet: Re: [erlang-questions] Running an erl program on a remote machine > > On 23/05/2011 16:12, phiroc@REDACTED wrote: >> Hello, >> >> is it possible to run an erlang program on a remote machine without using the erl console? >> >> For instance, let's say that I have written a program that runs a batch script and that I would like to run it on machine B at a set time. Can I create an entry in my machine's crontab which runs the following script: >> >> erl -name machineB -detached >> > Why would you want to do that? > Why not put that command directly in B's crontab? > > Carlo > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions - -- Parnell "ixmatus" Springmeyer (http://ixmat.us) -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJN2tSfAAoJEPvtlbpI1POLeLQH/RDeKBsjW1HyhExU4qTDSpGV ebBesrAaJ0NCl+VFIx0n/p9m8C0KnWL5RsZjH74PQJruaG3BA9bT9LGlCIc+3EEF QfM42OmArCujvlnbCSmE+ntRCJIWTTSSGBEJE4sMtDbeGiGjOib+4AT5Q8IkHFIT +UYL+AZwqMJwu3MmNc3OIpq26amCzM0UAZ/05AXSPusIUU8oVnh48tyawyfsTq6F J2z5TlcHbsNqi0aloGq2vXqshUvtZ3wnAyw33ze88UTNDE5eC0dLrf1ING2mZLt1 is6YyHENxhdtrD6pKXipeBLzMu8TJQf0rI8+keFMvVFngeF85JRZuSuGI42D/84= =VaNN -----END PGP SIGNATURE----- From ebegumisa@REDACTED Tue May 24 00:06:27 2011 From: ebegumisa@REDACTED (Edmond Begumisa) Date: Tue, 24 May 2011 08:06:27 +1000 Subject: [erlang-questions] QuickCheck/PropEr In-Reply-To: References: <319EB5973BAA42579692F3000F036E22@JohnsTablet2009> Message-ID: On Tue, 24 May 2011 05:24:53 +1000, Edmond Begumisa wrote: > Thanks John, > > This was most helpful and got me over that initial hurdle. I see now > that property-based testing is more about defining how the system should > behave and is best used as a design-time aid -- almost like programming > by contract. Write properties first, code from there. Thinking of it the > other way had caused me great confusion. > > With some head-scratching, I can now (usually) retrospectively come up > with properties for my libraries and codecs after watching this. > > But now I have a different problem! Libraries and codecs were at the > bottom of my list for things I wanted to do automated tests on coz these > don't fail much (time constrains mean I can ignore them for now). State > machines and IPC are at the top. I know -- I'm jumping straight into the > deep end. But I need to test the complex stuff in my apps rather than > the simpler stuff! > > Knowing that these are features for the commercial version of > QuickCheck, I'll direct the following silly questions to PropEr users > instead: > > * proper_fsm now makes more sense (reminds me a little of UBF(C)). But > I'm having trouble with defining properties for my gen_servers. This wasn't clear. I'm making headway with my gen_fsms thanks to proper_fsm. It's my gen_servers where I can't pass go. > From what I can tell, I need to somehow use {set, {var, _}, {call, _}} > symbolic reps for the callbacks. Something I realised from watching ... > > http://www.quviq.com/demos/QuickCheck%20Elevator%20Demo/QuickCheck%20Elevator%20Demo.htm > > .. and from "Testing Stateful Code" in PropEr's README. But I can't > figure out how to actually write the properties with symbolic reps for > the callbacks. Can anyone offer me an example on how to do this? > > * If I want to test a group of modules/processes rather than just one. > Specifically, a subtree in my supervision tree. How would I go about > doing this? Using the elevator example: say elevator.erl spawns several > people processes defined by person.erl. I write properties for both > modules and test them individually. But if I want to then write > properties that depend on actual interaction between elevator.erl and > several person.erl processes, where would I start? > > Thanks in advance for any help. > > - Edmond - > > > > > On Sun, 22 May 2011 20:20:06 +1000, John Hughes > wrote: > >> Hi Edmond, >> >> You're not alone--there is a hurdle to get over, a different way of >> thinking about testing. My talk at the last Erlang Factory in SF was >> specifically intended to help people just starting out--the video and >> slides are on the web at >> http://www.erlang-factory.com/conference/SFBay2011/speakers/JohnHughes. >> Be interested to hear if you find it helpful/not helpful. >> >> John >> >> >> ----- Original Message ----- From: "Edmond Begumisa" >> >> To: >> Sent: Sunday, May 22, 2011 12:01 AM >> Subject: [erlang-questions] QuickCheck >> >> >>> Hello all, >>> >>> I'm a QuickCheck noob trying out PropEr. Actually, I'm very >>> embarrassed to admit that I'm very new to formal testing in general >>> (I've always done things in the ad-hoc way for longer than I care to >>> admit). I only confess to this coz I probably wouldn't get away with >>> lying about it on *this* list when I start asking stupid questions! >>> >>> Anyways, I'm having A LOT of trouble getting started. The initial >>> inertia just isn't there. Even with the available documentation from >>> both QuviQ and PropEr. I look at my code and don't know where to begin >>> writing tests for it! A sad state of affairs. >>> >>> I think I just need a few good tutorials. Can anyone recommend some >>> QuickCheck resources to get me going that they've actually >>> successfully used? Do I need to first start out with more >>> "traditional" testing tools first before even attempting QuickCheck? >>> >>> Thanks in advance for you help. >>> >>> - Edmond - >>> >>> -- Using Opera's revolutionary e-mail client: >>> http://www.opera.com/mail/ >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >> > > -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From ebegumisa@REDACTED Tue May 24 00:13:06 2011 From: ebegumisa@REDACTED (Edmond Begumisa) Date: Tue, 24 May 2011 08:13:06 +1000 Subject: [erlang-questions] Running an erl program on a remote machine In-Reply-To: <30753908.2435881306162542010.JavaMail.root@spooler3-g27.priv.proxad.net> References: <30753908.2435881306162542010.JavaMail.root@spooler3-g27.priv.proxad.net> Message-ID: An alternative: You could make use of the OTP SSH Application... * Have mirror start an Erlang daemon that does nothing but run the OTP SSH application (an empty dumb server.) The SSH OTP Application gives you a secure shell from which you can remotely run Erlang commands from an ordinary SSH client. * From machinex, using any SSH client, send each mirror the script you want to run. You could type it in as expressions or use the SFTP subsystem of the OTP SSH application to push an escript. * This script should tell the mirror... 1. How it should determine if it is THE_CURRENT_MACHINE, 2. What DB commands it should run if it does and when * The mirrors are now no longer dependent on machinex being alive. * When you need to change the script, SSH again into the mirrors, send the new scripts. DOWN-SIDE: You'll have Erlang emulator process always running on the mirrors (but it won't be doing anything most of the time, so you probably need not worry about wasting resources.) UP-SIDE: You'll have Erlang daemons on each mirror that you can remotely turn into anything you want whenever you want. - Edmond - On Tue, 24 May 2011 00:55:42 +1000, wrote: > > Hi, > > I have been asked to write a script which runs database commands on one > of n > mirror machines. The name of the machine the commands should be run on is > contained in a DNS alias called, say, THE_CURRENT_MACHINE. In other > words, > if the THE_CURRENT_MACHINE alias resolves to machineA.company.com, > then the script should be run on that machine, if it resolves to > machineB.company.com, it should run on machine b, etc. > > I have thought of several ways of doing the above: > > - run a PERL script at a set time each day on a machine which I will call > machinex, which resolves the THE_CURRENT_MACHINE alias, connects to > it via SSH and runs the database commands. The disadvantage of > this solution is that, if machinex is down, the PERL script won't be run. > > - run a PERL script at a set time each day on machines A and B (and C > and D...) > makes sure that the current machine's name is equal to > THE_CURRENT_MACHINE value, > and, if that is the case, runs the database commands. > The disadvantage of this solution is that if I have 10 machines, I > must duplicate the script on those ten machines. > > - write an Erlang program which create a remote process on > THE_CURRENT_MACHINE that > runs the database commands, if it is feasible. Once again, if machinex > is down, > the program won't be run. > > - write an Erlang script which will run as a daemon on machines A, B, > C... > which checks every second if the time matches the time at which the > database > commands should be triggered, and, if that is the case, run them. > > If I had never heard of Erlang and of its alleged "spawn a remote > process" capabilities, > I would opt for solution 2 above. If you fellows have a better solution, > please let me know. > > Philippe > > > > > ----- Mail Original ----- > De: "Carlo Bertoldi" > ?: erlang-questions@REDACTED > Envoy?: Lundi 23 Mai 2011 16:20:24 GMT +01:00 Amsterdam / Berlin / Berne > / Rome / Stockholm / Vienne > Objet: Re: [erlang-questions] Running an erl program on a remote machine > > On 23/05/2011 16:12, phiroc@REDACTED wrote: >> Hello, >> >> is it possible to run an erlang program on a remote machine without >> using the erl console? >> >> For instance, let's say that I have written a program that runs a batch >> script and that I would like to run it on machine B at a set time. Can >> I create an entry in my machine's crontab which runs the following >> script: >> >> erl -name machineB -detached> batch script> >> > Why would you want to do that? > Why not put that command directly in B's crontab? > > Carlo > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From g@REDACTED Tue May 24 00:24:32 2011 From: g@REDACTED (Garrett Smith) Date: Mon, 23 May 2011 17:24:32 -0500 Subject: [erlang-questions] Running an erl program on a remote machine In-Reply-To: <30753908.2435881306162542010.JavaMail.root@spooler3-g27.priv.proxad.net> References: <2943760.2435381306162354145.JavaMail.root@spooler3-g27.priv.proxad.net> <30753908.2435881306162542010.JavaMail.root@spooler3-g27.priv.proxad.net> Message-ID: Hi Philippe, On Mon, May 23, 2011 at 9:55 AM, wrote: > > Hi, > > I have been asked to write a script which runs database commands on one of n > mirror machines. The name of the machine the commands should be run on is > contained in a DNS alias called, say, THE_CURRENT_MACHINE. In other words, > if the THE_CURRENT_MACHINE alias resolves to machineA.company.com, > ?then the script should be run on that machine, if it resolves to > ?machineB.company.com, it should run on machine b, etc. > > I have thought of several ways of doing the above: > > - run a PERL script at a set time each day on a machine which I will call > machinex, which resolves the THE_CURRENT_MACHINE alias, connects to > it via SSH and runs the database commands. The disadvantage of > this solution is that, if machinex is down, the PERL script won't be run. IMO, this is by far the best option if you don't already have an agent framework (e.g. Erlang nodes, Fabric, Puppet) running on each of the database servers. Running and maintaining agents on servers is nontrivial when compared to firing off a script over ssh. Have the script available on more than one machine for fail over -- which is a drop dead simple problem for rsync, git, scp, etc. > - run a PERL script at a set time each day on machines A and B (and C and D...) > makes sure that the current machine's name is equal to THE_CURRENT_MACHINE value, > and, if that is the case, runs the database commands. > The disadvantage of this solution is that if I have 10 machines, I > must duplicate the script on those ten machines. This requires you to sync on something. If you plan on using DNS, you need to make sure your DNS clients are in fact getting the latest/consistent records for the "current machine". If you've worked with DNS, you know it's forte is not consistency :) > - write an Erlang program which create a remote process on THE_CURRENT_MACHINE that > runs the database commands, if it is feasible. Once again, if machinex is down, > the program won't be run. Even if you wanted to use this a foray into distributed Erlang, I think you could find a better application. > - write an Erlang script which will run as a daemon on machines A, B, C... > which checks every second if the time matches the time at which the database > commands should be triggered, and, if that is the case, run them. This sounds like cron, which you should probably use if you want to run something on each server. But I still think an ssh command is the obvious choice. > If I had never heard of Erlang and of its alleged "spawn a remote process" capabilities, > I would opt for solution 2 above. If you fellows have a better solution, please let me know. > > Philippe -snip- From ebegumisa@REDACTED Tue May 24 00:30:56 2011 From: ebegumisa@REDACTED (Edmond Begumisa) Date: Tue, 24 May 2011 08:30:56 +1000 Subject: [erlang-questions] Calling multiple processes simultaneously In-Reply-To: References: <4DDA84D3.4060400@gmail.com> Message-ID: OH, I of course assumed the gen_server call was heavy enough to warrant a new process for each call otherwise you wouldn't have needed to abandon your existing loop looking for a way to call them all simultaneously. - Edmond - On Tue, 24 May 2011 06:54:23 +1000, Edmond Begumisa wrote: > Actually, > > {reply, ok, _} = gen_server:call(foo, bar), > > ...should be ... > > _ = gen_server:call(foo, bar), > > ... since you don't care about the reply, but just want a reply. > > - Edmond - > > On Tue, 24 May 2011 06:50:54 +1000, Edmond Begumisa > wrote: > >> Another option... >> >> call_gen_servers(Pids) -> >> Ref = erlang:make_ref(), >> Caller = self(), >> lists:foreach(fun(P) -> >> spawn_link(fun() -> >> {reply, ok, _} = >> gen_server:call(foo, bar), >> Caller ! {self(), Ref} >> end). >> end, Pids), >> ok = wait_gen_servers(length(Pids), Ref). >> >> wait_gen_servers(0, _) -> >> ok; >> wait_gen_servers(N, Ref) -> >> receive >> {_, Ref} -> >> wait_gen_servers(N-1, Ref) >> end. >> >> You could also add the timeout. >> >> - Edmond - >> >> On Tue, 24 May 2011 02:01:23 +1000, Martin Dimitrov >> wrote: >> >>> Hi, please, advise on this one, >>> >>> We have several hundred processes (gen_servers) . At one point the >>> program has to send them a message that needs to be handled before the >>> calling process can continue executing. This naturally led us to use >>> gen_server:call in loop over the processes. >>> >>> I started to wonder if there is a more efficient way of doing it since >>> the calling process doesn?t care about the return value ? just needs to >>> be sure that all processes had handled the message. Can we somehow call >>> the processes simultaneously? Something similar to >>> gen_server:multi_call >>> but for one node with different processes? >>> >>> Regards, >>> >>> Martin >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> >> > > -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From fritchie@REDACTED Tue May 24 00:34:06 2011 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Mon, 23 May 2011 17:34:06 -0500 Subject: [erlang-questions] QuickCheck/PropEr In-Reply-To: Message of "Tue, 24 May 2011 05:24:53 +1000." Message-ID: <39276.1306190046@snookles.snookles.com> Edmond Begumisa wrote: eb> . and from "Testing Stateful Code" in PropEr's README. But I can't eb> figure out how to actually write the properties with symbolic reps eb> for the callbacks. Can anyone offer me an example on how to do this? Keeping in mind that these tests were written with full QuickCheck(*), here are some stateful examples, using either eqc_statem or eqc_fsm: https://github.com/basho/riak_core/blob/master/test/node_watcher_qc.erl https://github.com/slfritchie/bitcask/blob/slf-rb-tree-hack2/test/rb_eqc.erl (Also uses eqc_c for testing C code (very fun!), namely a red-black tree) https://github.com/basho/bitcask/blob/master/test/bitcask_qc_fsm.erl https://github.com/basho/riak_kv/blob/master/test/backend_eqc.erl https://github.com/basho/riak_kv/blob/master/test/get_fsm_qc.erl (Not using eqc_statem or eqc_fsm, but used for testing a gen_fsm module) -Scott (*) Technically it's just "QuickCheck"? Hm, I like the sound of "QuickCheck Jumbo" From g@REDACTED Tue May 24 00:42:40 2011 From: g@REDACTED (Garrett Smith) Date: Mon, 23 May 2011 17:42:40 -0500 Subject: [erlang-questions] Erlang with Thrift In-Reply-To: References: Message-ID: On Mon, May 23, 2011 at 1:44 PM, Mike Oxford wrote: > Thrift's RPC mechanism is very one-way. > Is anyone pipelining the Thift protocol over erlang sockets? ?I cannot seem > to find any examples via Google. As in sending Thrift encoded payload as messages in distributed Erlang? If you can get away from Thrift (e.g. no one else is relying on it or you can't talk them off the cliff) I'd stick Erlang terms. BERT is a decent way to let other languages play along, otherwise there are usually language specific Erlang term conversion libraries. If you're locked into Thrift, the Erlang bindings work fine for encoding and decoding terms as per the Thrift docs. You need to dig into the code for these modules: thrift_memory_buffer, thrift_binary_protocol/thrift_protocol, and thrift_transport. Examples for other languages should translate directly to those. Garrett From hynek@REDACTED Tue May 24 00:43:07 2011 From: hynek@REDACTED (Hynek Vychodil) Date: Tue, 24 May 2011 00:43:07 +0200 Subject: [erlang-questions] Binary manipulation In-Reply-To: <4D7DE38D.4040005@bobcowdery.plus.com> References: <361084166.54601300011769241.JavaMail.root@zimbra> <4D7DE38D.4040005@bobcowdery.plus.com> Message-ID: Processing your binary in way decode(Bin) -> [ {I,Q} || <> <= Bin ]. encode(Data) -> << <> || {I,Q} <- Data >>. or roughly equivalent decode(<<>>) -> []; decode(<>) -> [ {I,Q} | decode(Rest) ]. encode(Data) -> encode(Data, <<>>). encode([], Result) -> Result; encode([{I,Q}|T], Acc) -> encode(T, <>). should be good enough especially compiled with HiPE unless you *measure* it is not. On Mon, Mar 14, 2011 at 10:44 AM, Bob Cowdery wrote: > Thanks. Sounds like I should move all the processing down into a > threaded C NIF. So I would pass back, in the case of decoding an empty > binary or a binary which is the multiple of 64 required. This can easily > be done on a separate thread as there are several calls to build one > response. Opposite on the encoding bit, pass back the largest list of > binaries that can be encoded from the multiple of 64 passed in. However, > this amounts to a polling loop from the erlang process waiting for the > result. ?That doesn't sound so great. Another alternative is to do all > that in a linked-in driver as it is a big chuck of C code that is > processing these large binaries anyway. Downside is that it breaks good > program structure. > > Bob > > On 13/03/2011 10:22, Lukas Larsson wrote: >> If you do write a nif call which could potentially take a long time you should use an async thread to do the work in it rather than doing it in the erlang vm thread. If not you could get some strange behaviour out of the vm depending on how unlucky you are with processes scheduling and unrelated work which other processes do. See http://www.erlang.org/cgi-bin/ezmlm-cgi?4:mss:55980:201101:jconogbffcaogeijbdkl for details. >> >> Lukas >> >> >> ----- Original Message ----- >> From: "Bob Cowdery" >> To: erlang-questions@REDACTED >> Sent: Sunday, March 13, 2011 11:03:57 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna >> Subject: Re: [erlang-questions] Binary manipulation >> >> Having received only one private reply which would not really scale up >> and having looked quite closely at all the API's available I can't see >> any way to manipulate binary data with any efficiency. I am therefore >> thinking of doing a NIF library. ?However I'm a bit concerned about what >> the following statement means: >> >> "Avoid doing lengthy work in NIF calls as that may degrade the >> responsiveness of the VM. NIFs are called directly by the same scheduler >> thread that executed the calling Erlang code. The calling scheduler will >> thus be blocked from doing any other work until the NIF returns." >> >> I presume this just means the calling process cannot do any other work >> until the NIF returns and not that all processes can suffer degradation. >> >> Thanks >> Bob >> >> On 11/03/2011 09:01, Bob Cowdery wrote: >>> Hi >>> >>> I would appreciate any advice/ideas on how to efficiently handle a large >>> binary. >>> >>> The binary in question has a couple of protocol wrappers around it which >>> are no problem as the bit syntax easily copes with that. What I'm not >>> sure of is how to handle the data. >>> >>> <> >>> >>> What I have to do is extract I and Q which are 24 bit le values and end >>> up with another binary which is: >>> >>> <> >>> >>> Where I and Q are now floating point numbers. I will need M in the >>> future, but not right now. It's a little more complicated than that >>> because several of the raw data binaries will go into the processed >>> binary which will be a multiple of 64 up to 1024. >>> >>> I will also need to do the opposite, i.e. take the processed binary and >>> transform it back to the raw data binary. >>> >>> Thanks >>> Bob >>> >>> ________________________________________________________________ >>> erlang-questions (at) erlang.org mailing list. >>> See http://www.erlang.org/faq.html >>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >>> >> >> ________________________________________________________________ >> erlang-questions (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >> >> >> ________________________________________________________________ >> erlang-questions (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >> > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > -- --Hynek (Pichi) Vychodil Analyze your data in minutes. Share your insights instantly. Thrill your boss.? Be a data hero! Try GoodData now for free: www.gooddata.com From jack@REDACTED Tue May 24 00:51:52 2011 From: jack@REDACTED (Jack Moffitt) Date: Mon, 23 May 2011 16:51:52 -0600 Subject: [erlang-questions] Erlang with Thrift In-Reply-To: References: Message-ID: > If you can get away from Thrift (e.g. no one else is relying on it or > you can't talk them off the cliff) I'd stick Erlang terms. BERT is a > decent way to let other languages play along, otherwise there are > usually language specific Erlang term conversion libraries. Speaking of BERT, how are people dealing with the possibility that rogue/broken clients might fill up the atom table? jack. From kostis@REDACTED Tue May 24 00:53:53 2011 From: kostis@REDACTED (Kostis Sagonas) Date: Tue, 24 May 2011 01:53:53 +0300 Subject: [erlang-questions] QuickCheck/PropEr In-Reply-To: References: <319EB5973BAA42579692F3000F036E22@JohnsTablet2009> Message-ID: <4DDAE581.6060704@cs.ntua.gr> Edmond Begumisa wrote: > Thanks John, > > This was most helpful and got me over that initial hurdle. I see now > that property-based testing is more about defining how the system should > behave and is best used as a design-time aid -- almost like programming > by contract. Write properties first, code from there. Thinking of it the > other way had caused me great confusion. > > ... , I'll direct the following silly questions to PropEr users > instead: > > * proper_fsm now makes more sense (reminds me a little of UBF(C)). But > I'm having trouble with defining properties for my gen_servers. ... > > Thanks in advance for any help. Edmond, Sorry, but given the upcoming OTP release I have been swamped by other more urgent duties... I do not have any answers to your questions at this point in time (sorry about that) but I would like to mention that: 1. We are in the process of creating a PropEr web site where among other things there will be PropEr tutorials, examples and FAQ. Our intention is to have it ready by the Erlang Factory in London, so please be a bit patient. 2. My talk in London will be about PropEr and what it can do for you: http://www.erlang-factory.com/conference/London2011/speakers/KostisSagonas 3. The address you are using does not reach the PropEr users but its developers. We'll set up such a user mailing list once we properly announce the first version of our tool -- note that it is currently unannounced even though I am aware that it's already being used by quite a few companies and many Erlang developers out there. Best, Kostis From nem@REDACTED Tue May 24 01:31:05 2011 From: nem@REDACTED (Geoff Cant) Date: Mon, 23 May 2011 16:31:05 -0700 Subject: [erlang-questions] Erlang with Thrift In-Reply-To: References: Message-ID: <05392824-4E6D-486B-99F4-DAA7C0F40E61@erlang.geek.nz> On 2011-05-23, at 15:51 , Jack Moffitt wrote: >> If you can get away from Thrift (e.g. no one else is relying on it or >> you can't talk them off the cliff) I'd stick Erlang terms. BERT is a >> decent way to let other languages play along, otherwise there are >> usually language specific Erlang term conversion libraries. > > Speaking of BERT, how are people dealing with the possibility that > rogue/broken clients might fill up the atom table? > > jack. > The ngmoco bert-rpc server (ngbs) uses the 'safe' option to binary_to_term to avoid this problem: https://github.com/ngmoco/ngbs/blob/master/src/ngbs_bert.erl#L21 . Clients get a protocol/data error if they try to do this. The trade-off is that you then need to ensure that all the modules for your application are loaded before you start accepting Bert requests, as [safe] decoding will stop modules from being automatically loaded. ngbs has been stable in production use for six months or so, and recently got request evaluation timing support which has been useful for spotting latency problems in the exposed APIs. I'd be happy to answer questions about ngbs off-list too. Cheers, -- Geoff Cant From moxford@REDACTED Tue May 24 01:34:16 2011 From: moxford@REDACTED (Mike Oxford) Date: Mon, 23 May 2011 16:34:16 -0700 Subject: [erlang-questions] Erlang with Thrift In-Reply-To: References: Message-ID: On Mon, May 23, 2011 at 3:51 PM, Jack Moffitt wrote: > > If you can get away from Thrift (e.g. no one else is relying on it or > > you can't talk them off the cliff) I'd stick Erlang terms. BERT is a > > decent way to let other languages play along, otherwise there are > > usually language specific Erlang term conversion libraries. > > Speaking of BERT, how are people dealing with the possibility that > rogue/broken clients might fill up the atom table? > > jack. > Not use atoms anywhere in the protocol? -mox -------------- next part -------------- An HTML attachment was scrubbed... URL: From norton@REDACTED Tue May 24 02:23:18 2011 From: norton@REDACTED (Joseph Wayne Norton) Date: Tue, 24 May 2011 09:23:18 +0900 Subject: [erlang-questions] Erlang with Thrift In-Reply-To: References: Message-ID: Mox - There is a Thrift encoder/decoder over TCP/IP implemented as part of the UBF framework. https://github.com/norton/ubf-thrift The mapping between Thrift, UBF, and erlang terms is illustrated in this file: https://github.com/norton/ubf-thrift/blob/master/src/tbf.erl If you want any further examples or help, please feel free to contact me directly. thanks, On Tue, 24 May 2011 03:44:59 +0900, Mike Oxford wrote: > Thrift's RPC mechanism is very one-way. > > Is anyone pipelining the Thift protocol over erlang sockets? I cannot > seem > to find any examples via Google. > > Thanks! > -mox -- norton@REDACTED From yaohui1984@REDACTED Tue May 24 04:23:32 2011 From: yaohui1984@REDACTED (=?ISO-8859-1?B?eWFvaHVp?=) Date: Tue, 24 May 2011 10:23:32 +0800 Subject: [erlang-questions] erlang vm crash Message-ID: this is snapshot of erl_crash_dump =erl_crash_dump:0.1 Mon May 23 21:36:12 2011 Slogan: no next heap size found: -2135228426, offset 0 System version: Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:8:8] [rq:8] [async-threads:0] [hipe] [kernel-poll:true] Compiled: Thu Apr 28 19:11:20 2011 Taints: Atoms: 7069 =memory total: 25553054336 processes: 23539490208 processes_used: 23539487744 system: 2013564128 atom: 480377 atom_used: 461941 binary: 27786680 code: 4005697 ets: 330040 what does this mean? Slogan: no next heap size found: -2135228426, offset 0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From behdad.forghani@REDACTED Tue May 24 04:51:34 2011 From: behdad.forghani@REDACTED (Behdad Forghani) Date: Mon, 23 May 2011 21:51:34 -0500 Subject: [erlang-questions] ASN.1 PER Does Not Correctly Handle Value Range Size Constraint In-Reply-To: References: <4DD813ED.6080509@gmail.com> Message-ID: <4DDB1D36.9050201@gmail.com> Hi Kenneth, You are quite right about bit strings. I am not sure about SIZE OF. I had missed the (SIZE( This was a test I had written based on the following NBAP specification: HARQ-MemoryPartitioningInfoExtForMIMO ::= SEQUENCE (SIZE (4|6|8)) OF HARQ-MemoryPartitioningItem It is not a syntax error because ASN.1 grammar defines; TypeWithConstraint ::= . | SEQUENCE Constraint OF Type | But, I agree this is a semantic error. Thanks for clarifying this. Regards, Behdad Kenneth Lundin wrote: > Hi, > > You have spotted a weak point in the ASN.1 compiler but it is not the > type of wrong behaviour as > you think. > > For BIT STRING and SEQUENCE OF the standard defines that the following > constraints are > applicable: > - Single value, > - Contained Subtype > - Size constraint > > But not Value-range > > On Sat, May 21, 2011 at 9:35 PM, Behdad Forghani > wrote: > >> Hi, >> >> I have tested this on R14B02. >> >> I noticed that ASN.1 compiler does not handle value range size constraints >> for SEQUENCE OF and BIT STRING. >> >> For example: >> Abs ::= BIT STRING(0|1|7) >> > I don't know how to interpret Abs, what does it mean? i.e. the 0|1|7 > is it value 0, 1, 7? it is certainly not > the size since then you have to write (SIZE(0|1|7)) > > >> Bbs ::= BIT STRING(3..18) >> > This is a value range which is clearly not applicable (the compiler > should have rejected this) > > If you want a SIZE constraint you should write BIT STRING (SIZE(3..18)) > > >> Cbs ::= BIT STRING >> >> >> Abs has a size constraint of 0..7 and Bbs, 3..18. >> > These are not size constraints they are value ranges. Which are not applicable. > I have to check the standard regarding the union to see what it means > for a BIT STRING if it is > applicable at all. > >> All three of the above will be encoded identically as length indeterminant >> as 0x07DA. This is only correct for Cbs. The problem seems to be that >> encode_bit_string calls get_constraint(C,'SizeConstraint'). >> >> However the constraint for the Abs is a UNION and for Bbs a ValueRange. It >> seems to me the support for both constraints needs to be added. >> > No I don't think so. I think it should be added functionality to > reject constraints which are not applicable for the type in question. > >> Just FYI, trying to give something back to the community. If I am correct, I >> can easily fix it. In that case, can you enlighten me on how to submit my >> code changes? >> >> Behdad >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > /Kenneth Erlang/OTP, Ericsson > From behdad.forghani@REDACTED Tue May 24 05:05:30 2011 From: behdad.forghani@REDACTED (Behdad Forghani) Date: Mon, 23 May 2011 22:05:30 -0500 Subject: [erlang-questions] ASN.1 PER Does Not Correctly Handle Value Range Size Constraint In-Reply-To: <4DDB1D36.9050201@gmail.com> References: <4DD813ED.6080509@gmail.com> <4DDB1D36.9050201@gmail.com> Message-ID: <4DDB207A.2050602@gmail.com> Oops, I meant to delete the SIZE OF from my email, you are correct there as well. Behdad Forghani wrote: > Hi Kenneth, > > You are quite right about bit strings. I am not sure about SIZE OF. I > had missed the (SIZE( > > This was a test I had written based on the following NBAP specification: > HARQ-MemoryPartitioningInfoExtForMIMO ::= SEQUENCE (SIZE (4|6|8)) OF > HARQ-MemoryPartitioningItem > > It is not a syntax error because ASN.1 grammar defines; > TypeWithConstraint ::= > . > | > SEQUENCE Constraint OF Type > | > > But, I agree this is a semantic error. > > Thanks for clarifying this. > > Regards, > Behdad > > Kenneth Lundin wrote: >> Hi, >> >> You have spotted a weak point in the ASN.1 compiler but it is not the >> type of wrong behaviour as >> you think. >> >> For BIT STRING and SEQUENCE OF the standard defines that the following >> constraints are >> applicable: >> - Single value, >> - Contained Subtype >> - Size constraint >> >> But not Value-range >> >> On Sat, May 21, 2011 at 9:35 PM, Behdad Forghani >> wrote: >>> Hi, >>> >>> I have tested this on R14B02. >>> >>> I noticed that ASN.1 compiler does not handle value range size >>> constraints >>> for SEQUENCE OF and BIT STRING. >>> >>> For example: >>> Abs ::= BIT STRING(0|1|7) >> I don't know how to interpret Abs, what does it mean? i.e. the 0|1|7 >> is it value 0, 1, 7? it is certainly not >> the size since then you have to write (SIZE(0|1|7)) >> >>> Bbs ::= BIT STRING(3..18) >> This is a value range which is clearly not applicable (the compiler >> should have rejected this) >> >> If you want a SIZE constraint you should write BIT STRING (SIZE(3..18)) >> >>> Cbs ::= BIT STRING >>> >>> >>> Abs has a size constraint of 0..7 and Bbs, 3..18. >> These are not size constraints they are value ranges. Which are not >> applicable. >> I have to check the standard regarding the union to see what it means >> for a BIT STRING if it is >> applicable at all. >>> All three of the above will be encoded identically as length >>> indeterminant >>> as 0x07DA. This is only correct for Cbs. The problem seems to be that >>> encode_bit_string calls get_constraint(C,'SizeConstraint'). >>> >>> However the constraint for the Abs is a UNION and for Bbs a >>> ValueRange. It >>> seems to me the support for both constraints needs to be added. >> No I don't think so. I think it should be added functionality to >> reject constraints which are not applicable for the type in question. >>> Just FYI, trying to give something back to the community. If I am >>> correct, I >>> can easily fix it. In that case, can you enlighten me on how to >>> submit my >>> code changes? >>> >>> Behdad >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >> /Kenneth Erlang/OTP, Ericsson > From octopusfluff@REDACTED Tue May 24 06:06:24 2011 From: octopusfluff@REDACTED (Amy Lear) Date: Mon, 23 May 2011 21:06:24 -0700 Subject: [erlang-questions] System timers, now/0, and instrumentation Message-ID: While I was working on getting used to working in Erlang and doing some tests on various data constructs, I made an attempt to make some measurements on performance -- mostly out of curiosity, not out of an attempt to actually optimize -- when I started noticing some irregularities on my Windows 7 machine. On research, I've discovered I'm not the first to hit problems of strange variance in latency, and others in the past (example here: http://erlang.2086793.n4.nabble.com/How-to-make-the-Erlang-VM-predictible-when-spawning-processes-td2242097.html) have reported mysterious latencies in the teens of ms on Windows. After doing some more tests then eventually resorting to msdn, it became clear that the issue is one of clock granularity, but it's catching people off guard because of the guaranteed uniqueness of now/0 results. This results in the appearance of time passing when it hasn't. The issue here as I understand it is that the system clock itself can't report things in the microsecond range (msdn states the granularity is between 10ms and 15ms: http://msdn.microsoft.com/en-us/library/system.datetimeoffset.utcnow.aspx ), but the real values are being mangled to provide those guaranteed unique values. Given that now/0 is the obvious means of doing measurement for an erlang user -- and in fact the instrumentation tools that ship with erlang also appear to rely on it -- this results in puzzling and undesired behavior. My question is: Is there a way to do viable instrumentation in Erlang on Windows systems, or is it expected to use another system for instrumentation? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrtndimitrov@REDACTED Tue May 24 07:12:10 2011 From: mrtndimitrov@REDACTED (Martin Dimitrov) Date: Tue, 24 May 2011 08:12:10 +0300 Subject: [erlang-questions] Calling multiple processes simultaneously In-Reply-To: References: <4DDA84D3.4060400@gmail.com> Message-ID: <4DDB3E2A.5090604@gmail.com> Thanks all for the valuable feedback. Great suggestions. Regards, Martin On 5/24/2011 4:07 AM, Nikolas Bowe wrote: > grab the plists module and do plists:map or plists:foreach over your pids > with a fun that does the gen_server:call. > https://github.com/archaelus/plists > > plists is really handy. > > > On Tue, May 24, 2011 at 2:01 AM, Martin Dimitrov wrote: > >> Hi, please, advise on this one, >> >> We have several hundred processes (gen_servers) . At one point the >> program has to send them a message that needs to be handled before the >> calling process can continue executing. This naturally led us to use >> gen_server:call in loop over the processes. >> >> I started to wonder if there is a more efficient way of doing it since >> the calling process doesn?t care about the return value ? just needs to >> be sure that all processes had handled the message. Can we somehow call >> the processes simultaneously? Something similar to gen_server:multi_call >> but for one node with different processes? >> >> Regards, >> >> Martin >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> From erlang@REDACTED Tue May 24 08:55:33 2011 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 24 May 2011 08:55:33 +0200 Subject: [erlang-questions] Calling multiple processes simultaneously In-Reply-To: References: <4DDA84D3.4060400@gmail.com> Message-ID: You've just invented pmap :-) - this way of doing it obscures the logic of what's going on: pmap(fun() -> gen_server:call(...) end, Pids) All the round-trips to the server are done "almost in parallel" (assuming spawn in the initial loop is faster than the round-trip time to call a server) the execution time for this should be O(T) where T is the longest time for any server to reply. pmap/2 is on page 366 of my Erlang book in the module lib_misc.erl I put all small functions that are generally useful, and do not belong to any particular module in lib_misc.erl pmap(F, L) -> S = self(), %% make_ref() returns a unique reference %% we'll match on this later Ref = erlang:make_ref(), Pids = map(fun(I) -> spawn(fun() -> do_f(S, Ref, F, I) end) end, L), %% gather the results gather(Pids, Ref). do_f(Parent, Ref, F, I) -> Parent ! {self(), Ref, (catch F(I))}. gather([Pid|T], Ref) -> receive {Pid, Ref, Ret} -> [Ret|gather(T, Ref)] end; gather([], _) -> []. /Joe On Mon, May 23, 2011 at 10:50 PM, Edmond Begumisa < ebegumisa@REDACTED> wrote: > Another option... > > call_gen_servers(Pids) -> > Ref = erlang:make_ref(), > Caller = self(), > lists:foreach(fun(P) -> > spawn_link(fun() -> > {reply, ok, _} = gen_server:call(foo, > bar), > Caller ! {self(), Ref} > end). > end, Pids), > ok = wait_gen_servers(length(Pids), Ref). > > wait_gen_servers(0, _) -> > ok; > wait_gen_servers(N, Ref) -> > receive > {_, Ref} -> > wait_gen_servers(N-1, Ref) > end. > > You could also add the timeout. > > - Edmond - > > > On Tue, 24 May 2011 02:01:23 +1000, Martin Dimitrov < > mrtndimitrov@REDACTED> wrote: > > Hi, please, advise on this one, >> >> We have several hundred processes (gen_servers) . At one point the >> program has to send them a message that needs to be handled before the >> calling process can continue executing. This naturally led us to use >> gen_server:call in loop over the processes. >> >> I started to wonder if there is a more efficient way of doing it since >> the calling process doesn?t care about the return value ? just needs to >> be sure that all processes had handled the message. Can we somehow call >> the processes simultaneously? Something similar to gen_server:multi_call >> but for one node with different processes? >> >> Regards, >> >> Martin >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimo+erlang-questions@REDACTED Tue May 24 09:39:37 2011 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Tue, 24 May 2011 09:39:37 +0200 Subject: [erlang-questions] Calling multiple processes simultaneously In-Reply-To: References: <4DDA84D3.4060400@gmail.com> Message-ID: <20110524073937.GA25239@erix.ericsson.se> Hello. I am just jumping in here; because it sounds like you guys are trying to reinvent gen_server:multi_call/2..5. But I have not read all posts so there is probably something that invalidates it. Just wanted to point to it in case not.... And the code might be worth reading. You can probably forget all cruft about C-nodes and legacy nodes that can not do monitor (if it still is there), though. http://www.erlang.org/doc/man/gen_server.html#multi_call-2 / Raimo On Mon, May 23, 2011 at 01:20:23PM -0700, Geoff Cant wrote: > > gen_server:call boils down to > > call(Server, Msg, Timeout) -> > Ref = monitor(Server), % or make_ref() > Server ! {'$gen_call$', {self(), Ref}, Msg}, > receive > {Ref, Reply} -> Reply > {'DOWN', Ref, _, _, Reason} -> exit(Reason) > after Timeout -> > exit(timeout) > end. > > If you do: > barrier(Servers, Msg) -> [ gen_server:call(S, Msg) || S <- Servers ], > ok. > > Then you'll wait at least Servers*2 message delays, and at worst Servers > * the gen_server call default timeout (5s). > > You could do all the calls concurrently with something like: > > call(Servers, Msg, Timeout) -> > Refs = [{S, monitor(S)}|| S <- Servers], > [S ! {'$gen_call$', {self(), Ref}, Msg} > || {S, Ref} <- Refs ], > collect_replies(Refs, Timeout). > > collect_replies([], _) -> []; > collect_replies([{S, Ref} | Rest], Timeout) -> > receive > {Ref, Reply} -> [{S, Reply} | collect_replies(Rest, Timeout)]; > {'DOWN', Ref, _, _, Reason} -> [{S, {error, Reason}} | > collect_replies(Rest, Timeout)] > after Timeout -> > %% Timeout is now expired for all servers. > [{S, {error, timeout}} | collect_replies(Rest, 0)] > end. > > This contains a basic attempt to not wait N*Timeout at worst, but could > be made closer to 1 timeout max by measuring the time from entering > collect_replies to receiving a Ref message and subtracting that from > Timeout before recurring. > > This code doesn't handle all the special cases that gen:call does ( > https://github.com/erlang/otp/blob/master/lib/stdlib/src/gen.erl#L191 ), > but should illustrate the idea. > > -- > Geoff Cant > > Martin Dimitrov writes: > > > Hi, please, advise on this one, > > > > We have several hundred processes (gen_servers) . At one point the > > program has to send them a message that needs to be handled before the > > calling process can continue executing. This naturally led us to use > > gen_server:call in loop over the processes. > > > > I started to wonder if there is a more efficient way of doing it since > > the calling process doesn???t care about the return value ??? just needs to > > be sure that all processes had handled the message. Can we somehow call > > the processes simultaneously? Something similar to gen_server:multi_call > > but for one node with different processes? > > > > Regards, > > > > Martin > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From clist@REDACTED Tue May 24 09:57:45 2011 From: clist@REDACTED (Angel Alvarez) Date: Tue, 24 May 2011 09:57:45 +0200 Subject: [erlang-questions] Running an erl program on a remote machine In-Reply-To: <30753908.2435881306162542010.JavaMail.root@spooler3-g27.priv.proxad.net> References: <30753908.2435881306162542010.JavaMail.root@spooler3-g27.priv.proxad.net> Message-ID: <201105240957.45916.clist@uah.es> Use the slave module you can start an erlang vm on a remote host using SSH and a provided you have transfered yout erlang code there you can run remote process. Also you can load locally your code and send it to remote nodes via binaries or use the remote code server option on the slave modules... Just to start: erl -man slave On the code server: erl -man code /Angel El Lunes, 23 de Mayo de 2011 16:55:42 phiroc@REDACTED escribi?: > > Hi, > > I have been asked to write a script which runs database commands on one of n > mirror machines. The name of the machine the commands should be run on is > contained in a DNS alias called, say, THE_CURRENT_MACHINE. In other words, > if the THE_CURRENT_MACHINE alias resolves to machineA.company.com, > then the script should be run on that machine, if it resolves to > machineB.company.com, it should run on machine b, etc. > > I have thought of several ways of doing the above: > > - run a PERL script at a set time each day on a machine which I will call > machinex, which resolves the THE_CURRENT_MACHINE alias, connects to > it via SSH and runs the database commands. The disadvantage of > this solution is that, if machinex is down, the PERL script won't be run. > > - run a PERL script at a set time each day on machines A and B (and C and D...) > makes sure that the current machine's name is equal to THE_CURRENT_MACHINE value, > and, if that is the case, runs the database commands. > The disadvantage of this solution is that if I have 10 machines, I > must duplicate the script on those ten machines. > > - write an Erlang program which create a remote process on THE_CURRENT_MACHINE that > runs the database commands, if it is feasible. Once again, if machinex is down, > the program won't be run. > > - write an Erlang script which will run as a daemon on machines A, B, C... > which checks every second if the time matches the time at which the database > commands should be triggered, and, if that is the case, run them. > > If I had never heard of Erlang and of its alleged "spawn a remote process" capabilities, > I would opt for solution 2 above. If you fellows have a better solution, please let me know. > > Philippe > > > > > ----- Mail Original ----- > De: "Carlo Bertoldi" > ?: erlang-questions@REDACTED > Envoy?: Lundi 23 Mai 2011 16:20:24 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne > Objet: Re: [erlang-questions] Running an erl program on a remote machine > > On 23/05/2011 16:12, phiroc@REDACTED wrote: > > Hello, > > > > is it possible to run an erlang program on a remote machine without using the erl console? > > > > For instance, let's say that I have written a program that runs a batch script and that I would like to run it on machine B at a set time. Can I create an entry in my machine's crontab which runs the following script: > > > > erl -name machineB -detached > > > Why would you want to do that? > Why not put that command directly in B's crontab? > > Carlo > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Este correo no tiene dibujos. Las formas extra?as en la pantalla son letras. __________________________________________ Clist UAH a.k.a Angel AT uah DOT es Angel Alvarez , Servicios Inform?ticos Edificio Torre de Control, Campus Externo UAH Alcal? de Henares 28806, Madrid ** ESPA?A ** __________________________________________ If debugging is the process of removing bugs, then programming must be the process of putting them in. - Dijkstra. From erlang@REDACTED Tue May 24 10:06:19 2011 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 24 May 2011 10:06:19 +0200 Subject: [erlang-questions] Why do we need modules at all? Message-ID: Why do we need modules at all? This is a brain-dump-stream-of-consciousness-thing. I've been thinking about this for a while. I'm proposing a slightly different way of programming here The basic idea is - do away with modules - all functions have unique distinct names - all functions have (lots of) meta data - all functions go into a global (searchable) Key-value database - we need letrec - contribution to open source can be as simple as contributing a single function - there are no "open source projects" - only "the open source Key-Value database of all functions" - Content is peer reviewed These are discussed in no particular order below: Why does Erlang have modules? There's a good an bad side to modules: Good: Provides a unit of compilation, a unit of code distribution. unit of code replacement Bad: It's very difficult to decide which module to put an individual function in. Break encapsulation (see later) Aside: lib_misc.erl When I'm programming I often get to the point were I say there should a function foo/2 in lists.erl but their isn't. There should be but there isn't - foo/2 is a small self contained thing. Why should it be in lists.erl because it "feels right". Strings are lists, so why do we have two modules lists.erl and string.erl how should I decide in which module my new string/list processing function should go. To avoid all mental anguish when I need a small function that should be somewhere else and isn't I stick it in a module elib1_misc.erl. My elib1_misc exports the following: added_files/2 make_challenge/0 as_bits/1 make_response/2 as_bits_test/0 make_response_test/0 bdump/2 make_test_strings/1 bin2hex/1 make_test_strings_test/0 bin2hex_test/0 make_tmp_filename/2 check_io_list/1 merge_kv/1 collect_atom/1 merge_kv_test/0 collect_atom_test/0 mini_shell/0 collect_int/1 module_info/0 collect_int_test/0 module_info/1 collect_string/1 ndots/1 collect_string_test/0 nibble_to_hex_char/1 collect_word/1 nibble_to_hex_char_test/0 complete/2 odd/1 complete_test/0 on_exit/2 dos2unix/1 out_of_date/2 downcase_char/1 outfile/2 dump/2 padd/2 dump_tmp/2 perms/1 duplicates/1 perms_test/0 ensure_started/2 pmap/2 eval_file/1 pmap1/2 eval_file_test/0 pmap1_test/0 eval_string/1 pmap_test/0 eval_string_test/0 priority_receive/0 every/3 random_seed/0 expand_env_vars/1 random_string/1 expand_file_template/3 random_string/2 expand_string_template/2 read_at_most_n_lines/2 expand_tabs/1 read_at_most_n_lines_test/0 expand_tabs_test/0 remove_duplicates/1 expand_template/2 remove_duplicates_test/0 extract_attribute/2 remove_leading_and_trailing_whitespace/1 extract_attribute_test/0 remove_leading_and_trailing_whitespace_test/0 extract_prefix/2 remove_leading_whitespace/1 fetch/2 remove_prefix/2 fetch_test/0 remove_prefix_test/0 file2lines/1 remove_trailing_whitespace/1 file2lines_test/0 replace/3 file2md5/1 root_dir/0 file2numberedlines/1 rpc/2 file2numberedlines_test/0 safe/1 file2paras/1 show_loaded/1 file2stream/1 signed_byte_to_hex_string/1 file2string/1 signed_byte_to_hex_string_test/0 file2template/1 skip_blanks/1 file2term/1 skip_blanks_test/0 file_size_and_type/1 skip_to_nl/1 find_src/1 skip_to_nl_test/0 first/1 sleep/1 flatten_io_list/1 spawn_monitor/3 flush_buffer/0 split_at_char/2 for/3 split_at_char_test/0 force/1 split_list/2 foreach_chunk_in_file/3 split_list_test/0 foreach_word_in_file/2 string2exprs/1 foreach_word_in_string/2 string2exprs_test/0 forever/0 string2html/1 get_erl_section/2 string2latex/1 get_line/1 string2lines/1 get_line/2 string2lines_test/0 have_common_prefix/1 string2stream/1 have_common_prefix_test/0 string2stream_test/0 hex2bin/1 string2template/1 hex2bin_test/0 string2template_test/0 hex2list/1 string2term/1 hex2list_test/0 string2term_test/0 hex_nibble2int/1 string2toks/1 hex_nibble2int_test/0 string2toks_test/0 id/1 sub_binary/3 include_dir/0 template2file/3 include_file/1 term2file/2 interleave/2 term2string/1 is_alphanum/1 test/0 is_blank_line/1 test1_test/0 is_prefix/2 test_function_over_substrings/2 is_prefix_test/0 tex2pdf/1 is_response_correct/3 time_fun/2 keep_alive/2 time_stamp/0 lines2para/1 to_lower/1 list2frequency_distribution/1 to_lower_test/0 list2frequency_distribution_tetrim/1 longest_common_prefix/1 trim_test/0 longest_common_prefix_test/0 unconsult/2 lookup/2 unsigned_byte_to_hex_string/1 lorem/1 unsigned_byte_to_hex_string_test/0 ls/1 which/1 which_added/1 Now I find this very convenient when I write a new small utility function I stick in in elib1_misc.erl - no mental anguish in choosing a module name is involved. The observation that I find this very-convenient is telling me something about modules - I like my elib1_misc it feels right. (aside - It seems many development projects have their own private lib_miscs ...) Which brings me to the point of my question. Do we need module's at all? Erlang programs are composed of lots of small functions, the only place where modules seem useful is to hide a letrec. The classic example is fibonacci. We want to expose fib/1 but hide the helper function fib/3. Using modules we say -module(math). -export([fib/1]). fib(N) -> fib(N, 1, 0). fib(N, A, B) when N < 2 -> A; fib(N, A, B) -> fib(N-1, A+B, A). The downside is we have had to *invent* one module name math - whose *only* purpose is to hide the definition of fib/3 which we don't want to be made callable. If we put a second function into the module math, then this second function could call fib/3 which breaks the encapsulation of fib/3. We could say: let fib = fun(N) -> fib(N, 1, 0) end in fib(N, A, B) when N < 2 -> A; fib(N, A, B) -> fib(N-1, A+B, A). end. I hardly dare suggest a syntax for this since I've been following another thread in this forum where syntax discussion seem to encourage much comment. ** Please do suggest alternative syntax's here - but do not comment on other peoples suggestions ... I would like to just talk about why we have modules. Another question: Does the idea of a module come from the idea that functions have to be stored somewhere, so we store them in a file, and we slurp the file (as a unit) into the system, so the file becomes a module? If all the files were store by themselves in a database would this change things. I am thinking more and more that if would be nice to have *all* functions in a key_value database with unique names. lookup(foo,2) would get the definition foo foo/2 from a database. The unique names bit is interesting - is this a good idea. Qualified names (ie names like xxx:foo/2) or (a.b.c.foo/2) sounds like a good idea but but when I'm programming I have to invent the xxx or the a.b.c which is very difficult. It also involves the "decision problem" if the namespaces xxx and a.b.c already exist I have to *choose* which to put my new function in. I think there might be a case for alises here joe:foo/2 could be used while developing "joe" would expand to a horrible random local string the real name being ab123aZwerasch123123_foo/2 but I would not be able to publish my code or make it available to a third_part before I had chosen a sensible name. (( managing namespaces seems really tricky, a lot of peoople seem to thing that the problem goes away by adding "." 's to the name but managing a namespace with namees like foo.bar.baz.z is just as complex as managing a namespace with names like foo_bar_baz_z or names like 0x3af312a78a3f1ae123 - the problem is that we have to go from a symbolic name like www.a.b to a reference like 123.45.23.12 - but how do we discover the initial name www.a.b? - there are two answers - a) we are given the name (ie we click on a link) - we do not know the name but we search fo it )) When programs are small we can live with "just the code" in "a few modules" the ratio of code to meta data is high. When programs are large we need a lot of meta-data to understand them. I would like to see all functions with all meta-data in a data base. I'd like to say: lookup(foo,2,Attribute) when Attribute = code|source|documentation|type signatures|revision history|authors|... The more I think about it the more I think program development should viewed as changing the state of a Key-Value database. So I imagine: 1) all functions have unique names 2) there are no modules 3) we discover the name of a function by searching metadata describing the function in a database 4) all public functions (think open source) are in the same database We could make a system to do this. I think this would make open-source projects easier, since the granularity of contribution goes down. You could contribute a single function - not an entire application. (( A problem with GUT style open source projects is there is not one database of functions, I often what one function from this project, another function from another project -- the granularity of reusable parts should be the individual function. functions are really easy to reuse modules are more difficult to reuse entire applications are very difficult to reuse (Unless there are isolated through a communication channel)) Possible extensions. 1) Voting for promotion 2) A review process Given a raw database will *all* functions in it - we could derive an "approved" functions database. Popular functions could be moved to the approved database - the review process would need to be discussed - so kind of peer-review/wiki stuff. Comments? Volunteers? /Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From kuleshovmail@REDACTED Tue May 24 10:10:37 2011 From: kuleshovmail@REDACTED (Alexander Kuleshov) Date: Tue, 24 May 2011 08:10:37 +0000 Subject: [erlang-questions] Erlang gen_fsm transition to a new state Message-ID: Hello, I have erlang gen_fsm, my first state: begin({Nick}, _From, State) -> {reply, true, next_state, State}. Then i have: next_state(_Event, _From, State) -> io:format("Test \n") {reply, ok, begin, State}. But i don't seen Test note in shell How correctly transit to a new state? Thank you. From Ralf.Gans@REDACTED Tue May 24 10:11:32 2011 From: Ralf.Gans@REDACTED (Ralf P. Gans) Date: Tue, 24 May 2011 10:11:32 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: <2828B06B-E6FE-4D77-8107-1DBBAACCEF48@t-online.de> Hi, the ability to replace code in a running environment depends, to my knowledge, on modules. So modules prevent downtimes and allow 7/24 operation. cheers, Ralf On 24.05.2011, at 10:06, Joe Armstrong wrote: > Why do we need modules at all? > > This is a brain-dump-stream-of-consciousness-thing. I've been > thinking about this for a while. > > I'm proposing a slightly different way of programming here > The basic idea is > > - do away with modules > - all functions have unique distinct names > - all functions have (lots of) meta data > - all functions go into a global (searchable) Key-value database > - we need letrec > - contribution to open source can be as simple as > contributing a single function > - there are no "open source projects" - only "the open source > Key-Value database of all functions" > - Content is peer reviewed > > These are discussed in no particular order below: > > Why does Erlang have modules? > > There's a good an bad side to modules: > > Good: Provides a unit of compilation, a unit of code > distribution. unit of code replacement > > Bad: It's very difficult to decide which module to put an individual > function in. Break encapsulation (see later) > > Aside: lib_misc.erl > > When I'm programming I often get to the point were I say there should > a function foo/2 in lists.erl but their isn't. There should be but > there isn't - foo/2 is a small self contained thing. Why should it be > in lists.erl because it "feels right". > > Strings are lists, so why do we have two modules lists.erl and > string.erl how should I decide in which module my new string/list > processing function should go. > > To avoid all mental anguish when I need a small function that > should be somewhere else and isn't I stick it in > a module elib1_misc.erl. > > My elib1_misc exports the following: > > added_files/2 make_challenge/0 > as_bits/1 make_response/2 > as_bits_test/0 make_response_test/0 > bdump/2 make_test_strings/1 > bin2hex/1 make_test_strings_test/0 > bin2hex_test/0 make_tmp_filename/2 > check_io_list/1 merge_kv/1 > collect_atom/1 merge_kv_test/0 > collect_atom_test/0 mini_shell/0 > collect_int/1 module_info/0 > collect_int_test/0 module_info/1 > collect_string/1 ndots/1 > collect_string_test/0 nibble_to_hex_char/1 > collect_word/1 nibble_to_hex_char_test/0 > complete/2 odd/1 > complete_test/0 on_exit/2 > dos2unix/1 out_of_date/2 > downcase_char/1 outfile/2 > dump/2 padd/2 > dump_tmp/2 perms/1 > duplicates/1 perms_test/0 > ensure_started/2 pmap/2 > eval_file/1 pmap1/2 > eval_file_test/0 pmap1_test/0 > eval_string/1 pmap_test/0 > eval_string_test/0 priority_receive/0 > every/3 random_seed/0 > expand_env_vars/1 random_string/1 > expand_file_template/3 random_string/2 > expand_string_template/2 read_at_most_n_lines/2 > expand_tabs/1 read_at_most_n_lines_test/0 > expand_tabs_test/0 remove_duplicates/1 > expand_template/2 remove_duplicates_test/0 > extract_attribute/2 remove_leading_and_trailing_whitespace/1 > extract_attribute_test/0 remove_leading_and_trailing_whitespace_test/0 > extract_prefix/2 remove_leading_whitespace/1 > fetch/2 remove_prefix/2 > fetch_test/0 remove_prefix_test/0 > file2lines/1 remove_trailing_whitespace/1 > file2lines_test/0 replace/3 > file2md5/1 root_dir/0 > file2numberedlines/1 rpc/2 > file2numberedlines_test/0 safe/1 > file2paras/1 show_loaded/1 > file2stream/1 signed_byte_to_hex_string/1 > file2string/1 signed_byte_to_hex_string_test/0 > file2template/1 skip_blanks/1 > file2term/1 skip_blanks_test/0 > file_size_and_type/1 skip_to_nl/1 > find_src/1 skip_to_nl_test/0 > first/1 sleep/1 > flatten_io_list/1 spawn_monitor/3 > flush_buffer/0 split_at_char/2 > for/3 split_at_char_test/0 > force/1 split_list/2 > foreach_chunk_in_file/3 split_list_test/0 > foreach_word_in_file/2 string2exprs/1 > foreach_word_in_string/2 string2exprs_test/0 > forever/0 string2html/1 > get_erl_section/2 string2latex/1 > get_line/1 string2lines/1 > get_line/2 string2lines_test/0 > have_common_prefix/1 string2stream/1 > have_common_prefix_test/0 string2stream_test/0 > hex2bin/1 string2template/1 > hex2bin_test/0 string2template_test/0 > hex2list/1 string2term/1 > hex2list_test/0 string2term_test/0 > hex_nibble2int/1 string2toks/1 > hex_nibble2int_test/0 string2toks_test/0 > id/1 sub_binary/3 > include_dir/0 template2file/3 > include_file/1 term2file/2 > interleave/2 term2string/1 > is_alphanum/1 test/0 > is_blank_line/1 test1_test/0 > is_prefix/2 test_function_over_substrings/2 > is_prefix_test/0 tex2pdf/1 > is_response_correct/3 time_fun/2 > keep_alive/2 time_stamp/0 > lines2para/1 to_lower/1 > list2frequency_distribution/1 to_lower_test/0 > list2frequency_distribution_tetrim/1 > longest_common_prefix/1 trim_test/0 > longest_common_prefix_test/0 unconsult/2 > lookup/2 unsigned_byte_to_hex_string/1 > lorem/1 unsigned_byte_to_hex_string_test/0 > ls/1 which/1 > which_added/1 > > Now I find this very convenient when I write a new small utility function > I stick in in elib1_misc.erl - no mental anguish in choosing a module > name is involved. > > The observation that I find this very-convenient is telling me something > about modules - I like my elib1_misc it feels right. > > (aside - It seems many development projects have their own private > lib_miscs ...) > > Which brings me to the point of my question. > > Do we need module's at all? Erlang programs are composed of lots of small > functions, the only place where modules seem useful is to hide a letrec. > > The classic example is fibonacci. We want to expose fib/1 but hide the > helper function fib/3. Using modules we say > > -module(math). > -export([fib/1]). > > fib(N) -> > fib(N, 1, 0). > > fib(N, A, B) when N < 2 -> A; > fib(N, A, B) -> fib(N-1, A+B, A). > > The downside is we have had to *invent* one module name math - whose *only* > purpose is to hide the definition of fib/3 which we don't want to be made > callable. > > If we put a second function into the module math, then this second function > could call fib/3 which breaks the encapsulation of fib/3. > > We could say: > > let fib = fun(N) -> fib(N, 1, 0) end > in > fib(N, A, B) when N < 2 -> A; > fib(N, A, B) -> fib(N-1, A+B, A). > end. > > I hardly dare suggest a syntax for this since I've been following > another thread in this forum where syntax discussion seem to encourage > much comment. > > ** Please do suggest alternative syntax's here - but do not comment on > other peoples suggestions ... > > I would like to just talk about why we have modules. > > Another question: > > Does the idea of a module come from the idea that functions have to be > stored somewhere, so we store them in a file, and we slurp the > file (as a unit) into the system, so the file becomes a module? > > If all the files were store by themselves in a database would this > change things. > > I am thinking more and more that if would be nice to have *all* functions in > a key_value database with unique names. > > lookup(foo,2) would get the definition foo foo/2 from a database. > > The unique names bit is interesting - is this a good idea. Qualified > names (ie names like xxx:foo/2) or (a.b.c.foo/2) sounds like a good > idea but but when I'm programming I have to invent the xxx or the > a.b.c which is very difficult. It also involves the "decision problem" > if the namespaces xxx and a.b.c already exist I have to *choose* which > to put my new function in. > > I think there might be a case for alises here joe:foo/2 could be used > while developing "joe" would expand to a horrible random local string the > real name being ab123aZwerasch123123_foo/2 but I would not be able to > publish my code or make it available to a third_part before I had > chosen a sensible name. > > (( managing namespaces seems really tricky, a lot of peoople seem > to thing that the problem goes away by adding "." 's to the name > but managing a namespace with namees like foo.bar.baz.z is just as complex > as managing a namespace with names like foo_bar_baz_z or names like > 0x3af312a78a3f1ae123 - the problem is that we have to go from a symbolic > name like www.a.b to a reference like 123.45.23.12 - but how do we discover > the initial name www.a.b? - there are two answers - a) we are given the name > (ie we click on a link) - we do not know the name but we search fo it )) > > > When programs are small we can live with "just the code" in "a few > modules" the ratio of code to meta data is high. > > When programs are large we need a lot of meta-data to understand them. > > I would like to see all functions with all meta-data in a data base. > > I'd like to say: > > lookup(foo,2,Attribute) when Attribute = > > code|source|documentation|type signatures|revision history|authors|... > > The more I think about it the more I think program development should > viewed as changing the state of a Key-Value database. > > So I imagine: > > 1) all functions have unique names > 2) there are no modules > 3) we discover the name of a function by searching metadata > describing the function in a database > 4) all public functions (think open source) are in the same > database > > We could make a system to do this. > > I think this would make open-source projects easier, since the > granularity of contribution goes down. You could contribute > a single function - not an entire application. > > (( A problem with GUT style open source projects is there is > not one database of functions, I often what one function from > this project, another function from another project -- the > granularity of reusable parts should be the individual function. > > functions are really easy to reuse > modules are more difficult to reuse > entire applications are very difficult to reuse > (Unless there are isolated through a communication channel)) > > Possible extensions. > > 1) Voting for promotion > 2) A review process > > Given a raw database will *all* functions in it - we could derive an > "approved" functions database. > > Popular functions could be moved to the approved database - the > review process would need to be discussed - so kind of peer-review/wiki > stuff. > > Comments? > > Volunteers? > > /Joe > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From octopusfluff@REDACTED Tue May 24 10:19:55 2011 From: octopusfluff@REDACTED (Amy Lear) Date: Tue, 24 May 2011 01:19:55 -0700 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: <2828B06B-E6FE-4D77-8107-1DBBAACCEF48@t-online.de> References: <2828B06B-E6FE-4D77-8107-1DBBAACCEF48@t-online.de> Message-ID: On Tue, May 24, 2011 at 1:11 AM, Ralf P. Gans wrote: > Hi, > > the ability to replace code in a running environment depends, to my > knowledge, on modules. > > So modules prevent downtimes and allow 7/24 operation. > > cheers, Ralf > This is only true because that's the implementation we have. The VM's ability to maintain a couple of versions of a particular function could still be maintained on that granular a level.. ... Provided there's a way to, with atomicity, ensure that nothing calls the new version of a function without all of the related changes in associated functions rolling into the VM at the same time, since you may be moving quite a bit around if you find yourself refactoring a few functions to add new capabilities. And that IS something that is easier with modules as a complete unit of dependency. Is there a way in a clean semantic manner track cross-function dependencies (potentially through some type of version tags?) in such a code database? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mazen.harake@REDACTED Tue May 24 10:33:36 2011 From: mazen.harake@REDACTED (Mazen Harake) Date: Tue, 24 May 2011 10:33:36 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: Aren't you just redefining the problem? Your next problem is going to be to name more generic type of functions. Imagine you have 3 different search functions which do different things in different modules. Your solution would instead of: foo:search(), bar:search(), baz:search() give foo_search(), bar_search(), baz_search() now you want to add a function that does replace; but replace what? say you call it replace() now I want to make one because it is specific to my problem so I have a decision problem foo_replace() ? bar_replace() ? so I will end up defining a prefix so that my versions of functions (where they collide with the already existing ones) always are unique thus: mazen_replace() now everyone starts creating functions with prefixes, now they want to start extending other functions so they build a prefix before the those: mazen_foo_replace() and before you know it you will have 20 functions ending with "search()" where search means what ever the prefix hints at... So you are back to square -1 because now it is worse, you don't have modules and you don't have applications beacuse an application would become what modules was before it. In fact, this is already a problem, all my opensource applications (and non-opensource as well) have a prefix on the modules because I can't call all my server type modules "server" (there is no namespace). My 2 cents. /M On 24 May 2011 10:06, Joe Armstrong wrote: > Why do we need modules at all? > > This is a brain-dump-stream-of-consciousness-thing. I've been > thinking about this for a while. > > I'm proposing a slightly different way of programming here > The basic idea is > > - do away with modules > - all functions have unique distinct names > - all functions have (lots of) meta data > - all functions go into a global (searchable) Key-value database > - we need letrec > - contribution to open source can be as simple as > contributing a single function > - there are no "open source projects" - only "the open source > Key-Value database of all functions" > - Content is peer reviewed > > These are discussed in no particular order below: > > Why does Erlang have modules? > > There's a good an bad side to modules: > > Good: Provides a unit of compilation, a unit of code > distribution. unit of code replacement > > Bad: It's very difficult to decide which module to put an individual > function in. Break encapsulation (see later) > > Aside: lib_misc.erl > > When I'm programming I often get to the point were I say there should > a function foo/2 in lists.erl but their isn't. There should be but > there isn't - foo/2 is a small self contained thing. Why should it be > in lists.erl because it "feels right". > > Strings are lists, so why do we have two modules lists.erl and > string.erl how should I decide in which module my new string/list > processing function should go. > > To avoid all mental anguish when I need a small function that > should be somewhere else and isn't I stick it in > a module elib1_misc.erl. > > My elib1_misc exports the following: > > added_files/2 make_challenge/0 > as_bits/1 make_response/2 > as_bits_test/0 make_response_test/0 > bdump/2 make_test_strings/1 > bin2hex/1 make_test_strings_test/0 > bin2hex_test/0 make_tmp_filename/2 > check_io_list/1 merge_kv/1 > collect_atom/1 merge_kv_test/0 > collect_atom_test/0 mini_shell/0 > collect_int/1 module_info/0 > collect_int_test/0 module_info/1 > collect_string/1 ndots/1 > collect_string_test/0 nibble_to_hex_char/1 > collect_word/1 nibble_to_hex_char_test/0 > complete/2 odd/1 > complete_test/0 on_exit/2 > dos2unix/1 out_of_date/2 > downcase_char/1 outfile/2 > dump/2 padd/2 > dump_tmp/2 perms/1 > duplicates/1 perms_test/0 > ensure_started/2 pmap/2 > eval_file/1 pmap1/2 > eval_file_test/0 pmap1_test/0 > eval_string/1 pmap_test/0 > eval_string_test/0 priority_receive/0 > every/3 random_seed/0 > expand_env_vars/1 random_string/1 > expand_file_template/3 random_string/2 > expand_string_template/2 read_at_most_n_lines/2 > expand_tabs/1 read_at_most_n_lines_test/0 > expand_tabs_test/0 remove_duplicates/1 > expand_template/2 remove_duplicates_test/0 > extract_attribute/2 remove_leading_and_trailing_whitespace/1 > extract_attribute_test/0 remove_leading_and_trailing_whitespace_test/0 > extract_prefix/2 remove_leading_whitespace/1 > fetch/2 remove_prefix/2 > fetch_test/0 remove_prefix_test/0 > file2lines/1 remove_trailing_whitespace/1 > file2lines_test/0 replace/3 > file2md5/1 root_dir/0 > file2numberedlines/1 rpc/2 > file2numberedlines_test/0 safe/1 > file2paras/1 show_loaded/1 > file2stream/1 signed_byte_to_hex_string/1 > file2string/1 signed_byte_to_hex_string_test/0 > file2template/1 skip_blanks/1 > file2term/1 skip_blanks_test/0 > file_size_and_type/1 skip_to_nl/1 > find_src/1 skip_to_nl_test/0 > first/1 sleep/1 > flatten_io_list/1 spawn_monitor/3 > flush_buffer/0 split_at_char/2 > for/3 split_at_char_test/0 > force/1 split_list/2 > foreach_chunk_in_file/3 split_list_test/0 > foreach_word_in_file/2 string2exprs/1 > foreach_word_in_string/2 string2exprs_test/0 > forever/0 string2html/1 > get_erl_section/2 string2latex/1 > get_line/1 string2lines/1 > get_line/2 string2lines_test/0 > have_common_prefix/1 string2stream/1 > have_common_prefix_test/0 string2stream_test/0 > hex2bin/1 string2template/1 > hex2bin_test/0 string2template_test/0 > hex2list/1 string2term/1 > hex2list_test/0 string2term_test/0 > hex_nibble2int/1 string2toks/1 > hex_nibble2int_test/0 string2toks_test/0 > id/1 sub_binary/3 > include_dir/0 template2file/3 > include_file/1 term2file/2 > interleave/2 term2string/1 > is_alphanum/1 test/0 > is_blank_line/1 test1_test/0 > is_prefix/2 test_function_over_substrings/2 > is_prefix_test/0 tex2pdf/1 > is_response_correct/3 time_fun/2 > keep_alive/2 time_stamp/0 > lines2para/1 to_lower/1 > list2frequency_distribution/1 to_lower_test/0 > list2frequency_distribution_tetrim/1 > longest_common_prefix/1 trim_test/0 > longest_common_prefix_test/0 unconsult/2 > lookup/2 unsigned_byte_to_hex_string/1 > lorem/1 unsigned_byte_to_hex_string_test/0 > ls/1 which/1 > which_added/1 > > Now I find this very convenient when I write a new small utility function > I stick in in elib1_misc.erl - no mental anguish in choosing a module > name is involved. > > The observation that I find this very-convenient is telling me something > about modules - I like my elib1_misc it feels right. > > (aside - It seems many development projects have their own private > lib_miscs ...) > > Which brings me to the point of my question. > > Do we need module's at all? Erlang programs are composed of lots of small > functions, the only place where modules seem useful is to hide a letrec. > > The classic example is fibonacci. We want to expose fib/1 but hide the > helper function fib/3. Using modules we say > > -module(math). > -export([fib/1]). > > fib(N) -> > fib(N, 1, 0). > > fib(N, A, B) when N < 2 -> A; > fib(N, A, B) -> fib(N-1, A+B, A). > > The downside is we have had to *invent* one module name math - whose *only* > purpose is to hide the definition of fib/3 which we don't want to be made > callable. > > If we put a second function into the module math, then this second function > could call fib/3 which breaks the encapsulation of fib/3. > > We could say: > > let fib = fun(N) -> fib(N, 1, 0) end > in > fib(N, A, B) when N < 2 -> A; > fib(N, A, B) -> fib(N-1, A+B, A). > end. > > I hardly dare suggest a syntax for this since I've been following > another thread in this forum where syntax discussion seem to encourage > much comment. > > ** Please do suggest alternative syntax's here - but do not comment on > other peoples suggestions ... > > I would like to just talk about why we have modules. > > Another question: > > Does the idea of a module come from the idea that functions have to be > stored somewhere, so we store them in a file, and we slurp the > file (as a unit) into the system, so the file becomes a module? > > If all the files were store by themselves in a database would this > change things. > > I am thinking more and more that if would be nice to have *all* functions > in > a key_value database with unique names. > > lookup(foo,2) would get the definition foo foo/2 from a database. > > The unique names bit is interesting - is this a good idea. Qualified > names (ie names like xxx:foo/2) or (a.b.c.foo/2) sounds like a good > idea but but when I'm programming I have to invent the xxx or the > a.b.c which is very difficult. It also involves the "decision problem" > if the namespaces xxx and a.b.c already exist I have to *choose* which > to put my new function in. > > I think there might be a case for alises here joe:foo/2 could be used > while developing "joe" would expand to a horrible random local string the > real name being ab123aZwerasch123123_foo/2 but I would not be able to > publish my code or make it available to a third_part before I had > chosen a sensible name. > > (( managing namespaces seems really tricky, a lot of peoople seem > to thing that the problem goes away by adding "." 's to the name > but managing a namespace with namees like foo.bar.baz.z is just as complex > as managing a namespace with names like foo_bar_baz_z or names like > 0x3af312a78a3f1ae123 - the problem is that we have to go from a symbolic > name like www.a.b to a reference like 123.45.23.12 - but how do we discover > the initial name www.a.b? - there are two answers - a) we are given the > name > (ie we click on a link) - we do not know the name but we search fo it )) > > > When programs are small we can live with "just the code" in "a few > modules" the ratio of code to meta data is high. > > When programs are large we need a lot of meta-data to understand them. > > I would like to see all functions with all meta-data in a data base. > > I'd like to say: > > lookup(foo,2,Attribute) when Attribute = > > code|source|documentation|type signatures|revision > history|authors|... > > The more I think about it the more I think program development should > viewed as changing the state of a Key-Value database. > > So I imagine: > > 1) all functions have unique names > 2) there are no modules > 3) we discover the name of a function by searching metadata > describing the function in a database > 4) all public functions (think open source) are in the same > database > > We could make a system to do this. > > I think this would make open-source projects easier, since the > granularity of contribution goes down. You could contribute > a single function - not an entire application. > > (( A problem with GUT style open source projects is there is > not one database of functions, I often what one function from > this project, another function from another project -- the > granularity of reusable parts should be the individual function. > > functions are really easy to reuse > modules are more difficult to reuse > entire applications are very difficult to reuse > (Unless there are isolated through a communication channel)) > > Possible extensions. > > 1) Voting for promotion > 2) A review process > > Given a raw database will *all* functions in it - we could derive an > "approved" functions database. > > Popular functions could be moved to the approved database - the > review process would need to be discussed - so kind of peer-review/wiki > stuff. > > Comments? > > Volunteers? > > /Joe > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mazen.harake@REDACTED Tue May 24 10:36:48 2011 From: mazen.harake@REDACTED (Mazen Harake) Date: Tue, 24 May 2011 10:36:48 +0200 Subject: [erlang-questions] Erlang gen_fsm transition to a new state In-Reply-To: References: Message-ID: The state transitions are not automatic. You have to send an event to the FSM to "drive" it. Look at the documentation for various "send_event" functions. /M On 24 May 2011 10:10, Alexander Kuleshov wrote: > Hello, > > I have erlang gen_fsm, my first state: > > begin({Nick}, _From, State) -> > {reply, true, next_state, State}. > Then i have: > > next_state(_Event, _From, State) -> > io:format("Test \n") > {reply, ok, begin, State}. > But i don't seen Test note in shell > > How correctly transit to a new state? > > Thank you. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitrii@REDACTED Tue May 24 10:39:06 2011 From: dmitrii@REDACTED (Dmitrii Dimandt) Date: Tue, 24 May 2011 11:39:06 +0300 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: > > So I imagine: > > 1) all functions have unique names > 2) there are no modules > 3) we discover the name of a function by searching metadata > describing the function in a database > 4) all public functions (think open source) are in the same > database > > We could make a system to do this. Hm... you'd still need *some* kind of modules. For instance, in Webmachine each resource is expected to have some, or all, of predefined public/exported functions: to_html, resource_exists, allowed_methods etc. So, each resource will have functions with the same name. If we move all functions to a global namespace, then how do we differentiate between these functions? Probably by naming them resource_name_function_name? Furthermore, what do we do with behaviours? A behaviour is encapsulated within a module, also with a predefined set of exported funcions (and any number of custom exported functions). From kuleshovmail@REDACTED Tue May 24 10:41:39 2011 From: kuleshovmail@REDACTED (Alexander Kuleshov) Date: Tue, 24 May 2011 08:41:39 +0000 Subject: [erlang-questions] Erlang gen_fsm transition to a new state In-Reply-To: References: Message-ID: Hello, Thank you for reply. I do in I have erlang gen_fsm, my first state: begin({Nick}, _From, State) -> gen_fsm:send_event({global, State#state.id}, {start, Nick}), {reply, true, next_state, State}. Then i have: next_state({start, Nick}, State) -> io:format("Test \n"), {reply, ok, begin, State}. But it's doesn't work. From kuleshovmail@REDACTED Tue May 24 10:45:07 2011 From: kuleshovmail@REDACTED (Alexander Kuleshov) Date: Tue, 24 May 2011 08:45:07 +0000 Subject: [erlang-questions] Erlang gen_fsm transition to a new state In-Reply-To: References: Message-ID: Can i have any state_name/3 || /2 functions with different names? From gordon@REDACTED Tue May 24 10:48:09 2011 From: gordon@REDACTED (Gordon Guthrie) Date: Tue, 24 May 2011 09:48:09 +0100 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: There are two good things about modules: * they are a higher level of abstraction * they support good working practices Lets take a module that I use a little bit - and which a colleague introduced me to: http://erldocs.com/R14B02/stdlib/digraph.html?i=2&search=digra#get_digraph/1 I can use the couple of exposed functions of that that I know, confident that if it comes to it I can come back and master the rest of the interface later. I have confidence that there is a rubustness there that makes code using it maintainable. (my idea of maintainable is to be able to ignore most stuff, most of the time...). I can learn about the code at this higher level of abstraction. We too have a module with loads of random functions in it, well we have three (hn_util, util, util2), and each of them is just library functions. In the utility modules the ratio of exported to not-exported fns is maybe 7 to 1. In functional modules the exported/not ratio goes from 1-1 (in modules that define apis) to 1-3 against. If we had the (promised) -export-to() directive the number of pure exported fns would drop. Given that we build our testing strategy around -export() this separation is critical... Gordon On 24 May 2011 09:06, Joe Armstrong wrote: > Why do we need modules at all? > > This is a brain-dump-stream-of-consciousness-thing. I've been > thinking about this for a while. > > I'm proposing a slightly different way of programming here > The basic idea is > > ??? - do away with modules > ??? - all functions have unique distinct names > ??? - all functions have (lots of) meta data > ??? - all functions go into a global (searchable) Key-value database > ??? - we need letrec > ??? - contribution to open source can be as simple as > ????? contributing a single function > ??? - there are no "open source projects" - only "the open source > ????? Key-Value database of all functions" > ??? - Content is peer reviewed > > These are discussed in no particular order below: > > Why does Erlang have modules? > > There's a good an bad side to modules: > > Good: Provides a unit of compilation, a unit of code > distribution. unit of code replacement > > Bad: It's very difficult to decide which module to put an individual > function in. Break encapsulation (see later) > > Aside: lib_misc.erl > > When I'm programming I often get to the point were I say there should > a function foo/2 in lists.erl but their isn't. There should be but > there isn't - foo/2 is a small self contained thing. Why should it be > in lists.erl because it "feels right". > > Strings are lists, so why do we have two modules lists.erl and > string.erl how should I decide in which module my new string/list > processing function should go. > > To avoid all mental anguish when I need a small function that > should be somewhere else and isn't I stick it in > a module elib1_misc.erl. > > My elib1_misc exports the following: > > added_files/2???????????????? make_challenge/0 > as_bits/1???????????????????? make_response/2 > as_bits_test/0??????????????? make_response_test/0 > bdump/2?????????????????????? make_test_strings/1 > bin2hex/1???????????????????? make_test_strings_test/0 > bin2hex_test/0??????????????? make_tmp_filename/2 > check_io_list/1?????????????? merge_kv/1 > collect_atom/1??????????????? merge_kv_test/0 > collect_atom_test/0?????????? mini_shell/0 > collect_int/1???????????????? module_info/0 > collect_int_test/0??????????? module_info/1 > collect_string/1????????????? ndots/1 > collect_string_test/0???????? nibble_to_hex_char/1 > collect_word/1??????????????? nibble_to_hex_char_test/0 > complete/2??????????????????? odd/1 > complete_test/0?????????????? on_exit/2 > dos2unix/1??????????????????? out_of_date/2 > downcase_char/1?????????????? outfile/2 > dump/2??????????????????????? padd/2 > dump_tmp/2??????????????????? perms/1 > duplicates/1????????????????? perms_test/0 > ensure_started/2????????????? pmap/2 > eval_file/1?????????????????? pmap1/2 > eval_file_test/0????????????? pmap1_test/0 > eval_string/1???????????????? pmap_test/0 > eval_string_test/0??????????? priority_receive/0 > every/3?????????????????????? random_seed/0 > expand_env_vars/1???????????? random_string/1 > expand_file_template/3??????? random_string/2 > expand_string_template/2????? read_at_most_n_lines/2 > expand_tabs/1???????????????? read_at_most_n_lines_test/0 > expand_tabs_test/0??????????? remove_duplicates/1 > expand_template/2???????????? remove_duplicates_test/0 > extract_attribute/2?????????? remove_leading_and_trailing_whitespace/1 > extract_attribute_test/0????? remove_leading_and_trailing_whitespace_test/0 > extract_prefix/2????????????? remove_leading_whitespace/1 > fetch/2?????????????????????? remove_prefix/2 > fetch_test/0????????????????? remove_prefix_test/0 > file2lines/1????????????????? remove_trailing_whitespace/1 > file2lines_test/0???????????? replace/3 > file2md5/1??????????????????? root_dir/0 > file2numberedlines/1????????? rpc/2 > file2numberedlines_test/0???? safe/1 > file2paras/1????????????????? show_loaded/1 > file2stream/1???????????????? signed_byte_to_hex_string/1 > file2string/1???????????????? signed_byte_to_hex_string_test/0 > file2template/1?????????????? skip_blanks/1 > file2term/1?????????????????? skip_blanks_test/0 > file_size_and_type/1????????? skip_to_nl/1 > find_src/1??????????????????? skip_to_nl_test/0 > first/1?????????????????????? sleep/1 > flatten_io_list/1???????????? spawn_monitor/3 > flush_buffer/0??????????????? split_at_char/2 > for/3???????????????????????? split_at_char_test/0 > force/1?????????????????????? split_list/2 > foreach_chunk_in_file/3?????? split_list_test/0 > foreach_word_in_file/2??????? string2exprs/1 > foreach_word_in_string/2????? string2exprs_test/0 > forever/0???????????????????? string2html/1 > get_erl_section/2???????????? string2latex/1 > get_line/1??????????????????? string2lines/1 > get_line/2??????????????????? string2lines_test/0 > have_common_prefix/1????????? string2stream/1 > have_common_prefix_test/0???? string2stream_test/0 > hex2bin/1???????????????????? string2template/1 > hex2bin_test/0??????????????? string2template_test/0 > hex2list/1??????????????????? string2term/1 > hex2list_test/0?????????????? string2term_test/0 > hex_nibble2int/1????????????? string2toks/1 > hex_nibble2int_test/0???????? string2toks_test/0 > id/1????????????????????????? sub_binary/3 > include_dir/0???????????????? template2file/3 > include_file/1??????????????? term2file/2 > interleave/2????????????????? term2string/1 > is_alphanum/1???????????????? test/0 > is_blank_line/1?????????????? test1_test/0 > is_prefix/2?????????????????? test_function_over_substrings/2 > is_prefix_test/0????????????? tex2pdf/1 > is_response_correct/3???????? time_fun/2 > keep_alive/2????????????????? time_stamp/0 > lines2para/1????????????????? to_lower/1 > list2frequency_distribution/1 to_lower_test/0 > list2frequency_distribution_tetrim/1 > longest_common_prefix/1?????? trim_test/0 > longest_common_prefix_test/0? unconsult/2 > lookup/2????????????????????? unsigned_byte_to_hex_string/1 > lorem/1?????????????????????? unsigned_byte_to_hex_string_test/0 > ls/1????????????????????????? which/1 > ????????????????????????????? which_added/1 > > Now I find this very convenient when I write a new small utility function > I stick in in elib1_misc.erl - no mental anguish in choosing a module > name is involved. > > The observation that I find this very-convenient is telling me something > about modules - I like my elib1_misc it feels right. > > (aside - It seems many development projects have their own private > lib_miscs ...) > > Which brings me to the point of my question. > > Do we need module's at all? Erlang programs are composed of lots of small > functions, the only place where modules seem useful is to hide a letrec. > > The classic example is fibonacci. We want to expose fib/1 but hide the > helper function fib/3. Using modules we say > > -module(math). > -export([fib/1]). > > fib(N) -> > ??? fib(N, 1, 0). > > fib(N, A, B) when N < 2 -> A; > fib(N, A, B) -> fib(N-1, A+B, A). > > The downside is we have had to *invent* one module name math - whose *only* > purpose is to hide the definition of fib/3 which we don't want to be made > callable. > > If we put a second function into the module math, then this second function > could call fib/3 which breaks the encapsulation of fib/3. > > We could say: > > let fib = fun(N) -> fib(N, 1, 0) end > in > ?? fib(N, A, B) when N < 2 -> A; > ?? fib(N, A, B) -> fib(N-1, A+B, A). > end. > > I hardly dare suggest a syntax for this since I've been following > another thread in this forum where syntax discussion seem to encourage > much comment. > > ** Please do suggest alternative syntax's here - but do not comment on > other peoples suggestions ... > > I would like to just talk about why we have modules. > > Another question: > > Does the idea of a module come from the idea that functions have to be > stored somewhere, so we store them in a file, and we slurp the > file (as a unit) into the system, so the file becomes a module? > > If all the files were store by themselves in a database would this > change things. > > I am thinking more and more that if would be nice to have *all* functions in > a key_value database with unique names. > > lookup(foo,2) would get the definition foo foo/2 from a database. > > The unique names bit is interesting - is this a good idea. Qualified > names (ie names like xxx:foo/2) or (a.b.c.foo/2) sounds like a good > idea but but when I'm programming I have to invent the xxx or the > a.b.c which is very difficult. It also involves the "decision problem" > if the namespaces xxx and a.b.c already exist I have to *choose* which > to put my new function in. > > I think there might be a case for alises here joe:foo/2 could be used > while developing "joe" would expand to a horrible random local string the > real name being ab123aZwerasch123123_foo/2? but I would not be able to > publish my code or make it available to a third_part before I had > chosen a sensible name. > > (( managing namespaces seems really tricky, a lot of peoople seem > to thing that the problem goes away by adding "." 's to the name > but managing a namespace with namees like foo.bar.baz.z is just as complex > as managing a namespace with names like foo_bar_baz_z or names like > 0x3af312a78a3f1ae123 - the problem is that we have to go from a symbolic > name like www.a.b to a reference like 123.45.23.12 - but how do we discover > the initial name www.a.b? - there are two answers - a) we are given the name > (ie we click on a link) - we do not know the name but we search fo it )) > > > When programs are small we can live with "just the code" in "a few > modules" the ratio of code to meta data is high. > > When programs are large we need a lot of meta-data to understand them. > > I would like to see all functions with all meta-data in a data base. > > I'd like to say: > > ?? lookup(foo,2,Attribute) when Attribute = > > ????? code|source|documentation|type signatures|revision history|authors|... > > The more I think about it the more I think program development should > viewed as changing the state of a Key-Value database. > > So I imagine: > > ??? 1) all functions have unique names > ??? 2) there are no modules > ??? 3) we discover the name of a function by searching metadata > ?????? describing the function in a database > ??? 4) all public functions (think open source) are in the same > ?????? database > > We could make a system to do this. > > I think this would make open-source projects easier, since the > granularity of contribution goes down. You could contribute > a single function - not an entire application. > > (( A problem with GUT style open source projects is there is > ?? not one database of functions, I often what one function from > ?? this project, another function from another project -- the > ?? granularity of reusable parts should be the individual function. > > ?? functions are really easy to reuse > ?? modules are more difficult to reuse > ?? entire applications are very difficult to reuse > ???? (Unless there are isolated through a communication channel)) > > Possible extensions. > > ??? 1) Voting for promotion > ??? 2) A review process > > Given a raw database will *all* functions in it - we could derive an > "approved" functions database. > > Popular functions could be moved to the approved database - the > review process would need to be discussed - so kind of peer-review/wiki > stuff. > > Comments? > > Volunteers? > > /Joe > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- Gordon Guthrie CEO hypernumbers http://hypernumbers.com t: hypernumbers +44 7776 251669 From josh@REDACTED Tue May 24 10:49:00 2011 From: josh@REDACTED (Josh Johnston) Date: Tue, 24 May 2011 18:49:00 +1000 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: On 24/05/2011, at 6:39 PM, Dmitrii Dimandt wrote: >> >> So I imagine: >> >> 1) all functions have unique names >> 2) there are no modules >> 3) we discover the name of a function by searching metadata >> describing the function in a database >> 4) all public functions (think open source) are in the same >> database >> >> We could make a system to do this. > > Hm... you'd still need *some* kind of modules. > > For instance, in Webmachine each resource is expected to have some, or all, of predefined public/exported functions: to_html, resource_exists, allowed_methods etc. > > So, each resource will have functions with the same name. If we move all functions to a global namespace, then how do we differentiate between these functions? Probably by naming them resource_name_function_name? > In a normal language this would be a problem, but in erlang we can get the desired behaviour by using pattern matching, right? So instead of to_html() resource_exists() etc We have resource(to_html, ...) resource(exists, ...) etc I'm not disagreeing with you - we do need some good way to do this. But I don't think modules are necessary in this case. Josh. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gordon@REDACTED Tue May 24 10:49:30 2011 From: gordon@REDACTED (Gordon Guthrie) Date: Tue, 24 May 2011 09:49:30 +0100 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: ...and also... following on from what Dimitri said while I was writing me e-mail, we hang unit test onto modules and design them at that level of abstraction On 24 May 2011 09:48, Gordon Guthrie wrote: > There are two good things about modules: > * they are a higher level of abstraction > * they support good working practices > > Lets take a module that I use a little bit - and which a colleague > introduced me to: > http://erldocs.com/R14B02/stdlib/digraph.html?i=2&search=digra#get_digraph/1 > > I can use the couple of exposed functions of that that I know, > confident that if it comes to it I can come back and master the rest > of the interface later. I have confidence that there is a rubustness > there that makes code using it maintainable. (my idea of maintainable > is to be able to ignore most stuff, most of the time...). I can learn > about the code at this higher level of abstraction. > > We too have a module with loads of random functions in it, well we > have three (hn_util, util, util2), and each of them is just library > functions. In the utility modules the ratio of exported to > not-exported fns is maybe 7 to 1. > > In functional modules the exported/not ratio goes from 1-1 (in modules > that define apis) to 1-3 against. > > If we had the (promised) -export-to() directive the number of pure > exported fns would drop. > > Given that we build our testing strategy around -export() this > separation is critical... > > Gordon > > On 24 May 2011 09:06, Joe Armstrong wrote: >> Why do we need modules at all? >> >> This is a brain-dump-stream-of-consciousness-thing. I've been >> thinking about this for a while. >> >> I'm proposing a slightly different way of programming here >> The basic idea is >> >> ??? - do away with modules >> ??? - all functions have unique distinct names >> ??? - all functions have (lots of) meta data >> ??? - all functions go into a global (searchable) Key-value database >> ??? - we need letrec >> ??? - contribution to open source can be as simple as >> ????? contributing a single function >> ??? - there are no "open source projects" - only "the open source >> ????? Key-Value database of all functions" >> ??? - Content is peer reviewed >> >> These are discussed in no particular order below: >> >> Why does Erlang have modules? >> >> There's a good an bad side to modules: >> >> Good: Provides a unit of compilation, a unit of code >> distribution. unit of code replacement >> >> Bad: It's very difficult to decide which module to put an individual >> function in. Break encapsulation (see later) >> >> Aside: lib_misc.erl >> >> When I'm programming I often get to the point were I say there should >> a function foo/2 in lists.erl but their isn't. There should be but >> there isn't - foo/2 is a small self contained thing. Why should it be >> in lists.erl because it "feels right". >> >> Strings are lists, so why do we have two modules lists.erl and >> string.erl how should I decide in which module my new string/list >> processing function should go. >> >> To avoid all mental anguish when I need a small function that >> should be somewhere else and isn't I stick it in >> a module elib1_misc.erl. >> >> My elib1_misc exports the following: >> >> added_files/2???????????????? make_challenge/0 >> as_bits/1???????????????????? make_response/2 >> as_bits_test/0??????????????? make_response_test/0 >> bdump/2?????????????????????? make_test_strings/1 >> bin2hex/1???????????????????? make_test_strings_test/0 >> bin2hex_test/0??????????????? make_tmp_filename/2 >> check_io_list/1?????????????? merge_kv/1 >> collect_atom/1??????????????? merge_kv_test/0 >> collect_atom_test/0?????????? mini_shell/0 >> collect_int/1???????????????? module_info/0 >> collect_int_test/0??????????? module_info/1 >> collect_string/1????????????? ndots/1 >> collect_string_test/0???????? nibble_to_hex_char/1 >> collect_word/1??????????????? nibble_to_hex_char_test/0 >> complete/2??????????????????? odd/1 >> complete_test/0?????????????? on_exit/2 >> dos2unix/1??????????????????? out_of_date/2 >> downcase_char/1?????????????? outfile/2 >> dump/2??????????????????????? padd/2 >> dump_tmp/2??????????????????? perms/1 >> duplicates/1????????????????? perms_test/0 >> ensure_started/2????????????? pmap/2 >> eval_file/1?????????????????? pmap1/2 >> eval_file_test/0????????????? pmap1_test/0 >> eval_string/1???????????????? pmap_test/0 >> eval_string_test/0??????????? priority_receive/0 >> every/3?????????????????????? random_seed/0 >> expand_env_vars/1???????????? random_string/1 >> expand_file_template/3??????? random_string/2 >> expand_string_template/2????? read_at_most_n_lines/2 >> expand_tabs/1???????????????? read_at_most_n_lines_test/0 >> expand_tabs_test/0??????????? remove_duplicates/1 >> expand_template/2???????????? remove_duplicates_test/0 >> extract_attribute/2?????????? remove_leading_and_trailing_whitespace/1 >> extract_attribute_test/0????? remove_leading_and_trailing_whitespace_test/0 >> extract_prefix/2????????????? remove_leading_whitespace/1 >> fetch/2?????????????????????? remove_prefix/2 >> fetch_test/0????????????????? remove_prefix_test/0 >> file2lines/1????????????????? remove_trailing_whitespace/1 >> file2lines_test/0???????????? replace/3 >> file2md5/1??????????????????? root_dir/0 >> file2numberedlines/1????????? rpc/2 >> file2numberedlines_test/0???? safe/1 >> file2paras/1????????????????? show_loaded/1 >> file2stream/1???????????????? signed_byte_to_hex_string/1 >> file2string/1???????????????? signed_byte_to_hex_string_test/0 >> file2template/1?????????????? skip_blanks/1 >> file2term/1?????????????????? skip_blanks_test/0 >> file_size_and_type/1????????? skip_to_nl/1 >> find_src/1??????????????????? skip_to_nl_test/0 >> first/1?????????????????????? sleep/1 >> flatten_io_list/1???????????? spawn_monitor/3 >> flush_buffer/0??????????????? split_at_char/2 >> for/3???????????????????????? split_at_char_test/0 >> force/1?????????????????????? split_list/2 >> foreach_chunk_in_file/3?????? split_list_test/0 >> foreach_word_in_file/2??????? string2exprs/1 >> foreach_word_in_string/2????? string2exprs_test/0 >> forever/0???????????????????? string2html/1 >> get_erl_section/2???????????? string2latex/1 >> get_line/1??????????????????? string2lines/1 >> get_line/2??????????????????? string2lines_test/0 >> have_common_prefix/1????????? string2stream/1 >> have_common_prefix_test/0???? string2stream_test/0 >> hex2bin/1???????????????????? string2template/1 >> hex2bin_test/0??????????????? string2template_test/0 >> hex2list/1??????????????????? string2term/1 >> hex2list_test/0?????????????? string2term_test/0 >> hex_nibble2int/1????????????? string2toks/1 >> hex_nibble2int_test/0???????? string2toks_test/0 >> id/1????????????????????????? sub_binary/3 >> include_dir/0???????????????? template2file/3 >> include_file/1??????????????? term2file/2 >> interleave/2????????????????? term2string/1 >> is_alphanum/1???????????????? test/0 >> is_blank_line/1?????????????? test1_test/0 >> is_prefix/2?????????????????? test_function_over_substrings/2 >> is_prefix_test/0????????????? tex2pdf/1 >> is_response_correct/3???????? time_fun/2 >> keep_alive/2????????????????? time_stamp/0 >> lines2para/1????????????????? to_lower/1 >> list2frequency_distribution/1 to_lower_test/0 >> list2frequency_distribution_tetrim/1 >> longest_common_prefix/1?????? trim_test/0 >> longest_common_prefix_test/0? unconsult/2 >> lookup/2????????????????????? unsigned_byte_to_hex_string/1 >> lorem/1?????????????????????? unsigned_byte_to_hex_string_test/0 >> ls/1????????????????????????? which/1 >> ????????????????????????????? which_added/1 >> >> Now I find this very convenient when I write a new small utility function >> I stick in in elib1_misc.erl - no mental anguish in choosing a module >> name is involved. >> >> The observation that I find this very-convenient is telling me something >> about modules - I like my elib1_misc it feels right. >> >> (aside - It seems many development projects have their own private >> lib_miscs ...) >> >> Which brings me to the point of my question. >> >> Do we need module's at all? Erlang programs are composed of lots of small >> functions, the only place where modules seem useful is to hide a letrec. >> >> The classic example is fibonacci. We want to expose fib/1 but hide the >> helper function fib/3. Using modules we say >> >> -module(math). >> -export([fib/1]). >> >> fib(N) -> >> ??? fib(N, 1, 0). >> >> fib(N, A, B) when N < 2 -> A; >> fib(N, A, B) -> fib(N-1, A+B, A). >> >> The downside is we have had to *invent* one module name math - whose *only* >> purpose is to hide the definition of fib/3 which we don't want to be made >> callable. >> >> If we put a second function into the module math, then this second function >> could call fib/3 which breaks the encapsulation of fib/3. >> >> We could say: >> >> let fib = fun(N) -> fib(N, 1, 0) end >> in >> ?? fib(N, A, B) when N < 2 -> A; >> ?? fib(N, A, B) -> fib(N-1, A+B, A). >> end. >> >> I hardly dare suggest a syntax for this since I've been following >> another thread in this forum where syntax discussion seem to encourage >> much comment. >> >> ** Please do suggest alternative syntax's here - but do not comment on >> other peoples suggestions ... >> >> I would like to just talk about why we have modules. >> >> Another question: >> >> Does the idea of a module come from the idea that functions have to be >> stored somewhere, so we store them in a file, and we slurp the >> file (as a unit) into the system, so the file becomes a module? >> >> If all the files were store by themselves in a database would this >> change things. >> >> I am thinking more and more that if would be nice to have *all* functions in >> a key_value database with unique names. >> >> lookup(foo,2) would get the definition foo foo/2 from a database. >> >> The unique names bit is interesting - is this a good idea. Qualified >> names (ie names like xxx:foo/2) or (a.b.c.foo/2) sounds like a good >> idea but but when I'm programming I have to invent the xxx or the >> a.b.c which is very difficult. It also involves the "decision problem" >> if the namespaces xxx and a.b.c already exist I have to *choose* which >> to put my new function in. >> >> I think there might be a case for alises here joe:foo/2 could be used >> while developing "joe" would expand to a horrible random local string the >> real name being ab123aZwerasch123123_foo/2? but I would not be able to >> publish my code or make it available to a third_part before I had >> chosen a sensible name. >> >> (( managing namespaces seems really tricky, a lot of peoople seem >> to thing that the problem goes away by adding "." 's to the name >> but managing a namespace with namees like foo.bar.baz.z is just as complex >> as managing a namespace with names like foo_bar_baz_z or names like >> 0x3af312a78a3f1ae123 - the problem is that we have to go from a symbolic >> name like www.a.b to a reference like 123.45.23.12 - but how do we discover >> the initial name www.a.b? - there are two answers - a) we are given the name >> (ie we click on a link) - we do not know the name but we search fo it )) >> >> >> When programs are small we can live with "just the code" in "a few >> modules" the ratio of code to meta data is high. >> >> When programs are large we need a lot of meta-data to understand them. >> >> I would like to see all functions with all meta-data in a data base. >> >> I'd like to say: >> >> ?? lookup(foo,2,Attribute) when Attribute = >> >> ????? code|source|documentation|type signatures|revision history|authors|... >> >> The more I think about it the more I think program development should >> viewed as changing the state of a Key-Value database. >> >> So I imagine: >> >> ??? 1) all functions have unique names >> ??? 2) there are no modules >> ??? 3) we discover the name of a function by searching metadata >> ?????? describing the function in a database >> ??? 4) all public functions (think open source) are in the same >> ?????? database >> >> We could make a system to do this. >> >> I think this would make open-source projects easier, since the >> granularity of contribution goes down. You could contribute >> a single function - not an entire application. >> >> (( A problem with GUT style open source projects is there is >> ?? not one database of functions, I often what one function from >> ?? this project, another function from another project -- the >> ?? granularity of reusable parts should be the individual function. >> >> ?? functions are really easy to reuse >> ?? modules are more difficult to reuse >> ?? entire applications are very difficult to reuse >> ???? (Unless there are isolated through a communication channel)) >> >> Possible extensions. >> >> ??? 1) Voting for promotion >> ??? 2) A review process >> >> Given a raw database will *all* functions in it - we could derive an >> "approved" functions database. >> >> Popular functions could be moved to the approved database - the >> review process would need to be discussed - so kind of peer-review/wiki >> stuff. >> >> Comments? >> >> Volunteers? >> >> /Joe >> >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > > > > -- > Gordon Guthrie > CEO hypernumbers > > http://hypernumbers.com > t: hypernumbers > +44 7776 251669 > -- Gordon Guthrie CEO hypernumbers http://hypernumbers.com t: hypernumbers +44 7776 251669 From krab@REDACTED Tue May 24 10:53:34 2011 From: krab@REDACTED (Kresten Krab Thorup) Date: Tue, 24 May 2011 10:53:34 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: Modules have many uses, but they are often mixed up. Yesterday I made this drawing: -------------- next part -------------- A non-text attachment was scrubbed... Name: PastedGraphic-1.pdf Type: application/pdf Size: 33943 bytes Desc: PastedGraphic-1.pdf URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From rochus@REDACTED Tue May 24 11:00:19 2011 From: rochus@REDACTED (Nicolai Waniek) Date: Tue, 24 May 2011 11:00:19 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: <4DDB73A3.9020604@rochus.net> Hi, > - do away with modules If you want to get rid of modules you might want to have something like proper namespaces to place names into, because > - all functions have unique distinct names won't really work. Examples were already given (sort, replace, compression, etc) but will be easily extended to other functions as well, so you probably have to provide something to prevent a prefix-mess. Additionally, when thinking about something like removing modules but adding namespaces you might want to add some way to tell the compiler that every function invoked in the next function is from one specific namespace. Somewhat like C++ namespaces work (I don't say exactly as C++ namespaces work, just to get an idea...). > - all functions have (lots of) meta data As soon as you start to define functions with meta-data, wouldn't it be easier to simply invent a type system as, say, Haskell uses to prevent meta-data? I like functions short and nice, bloating them with meta-data won't do any good. > - all functions go into a global (searchable) Key-value database You would have to provide a way to go back to older 'revisions' of your key-value database. For example you introduce a new function that breaks some stuff (bug wasn't found when doing peer-review), you'd like to be able to revert to an older state, or easily bisect your code. This could be accomplished by seeing the key-value database in a functional manner: it's immutable. If you want to introduce a new function, the new one gets a new tag/whatever and a new function-db will replace the whole old one. Therefore you can simply step through your function-database when things go wrong. Regards, Nicolai From vladdu55@REDACTED Tue May 24 11:00:23 2011 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Tue, 24 May 2011 11:00:23 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: Hi, On Tue, May 24, 2011 at 10:06, Joe Armstrong wrote: > Do we need module's at all? Erlang programs are composed of lots of small > functions, the only place where modules seem useful is to hide a letrec. > > The classic example is fibonacci. We want to expose fib/1 but hide the > helper function fib/3. Using modules we say > > -module(math). > -export([fib/1]). > > fib(N) -> > fib(N, 1, 0). > > fib(N, A, B) when N < 2 -> A; > fib(N, A, B) -> fib(N-1, A+B, A). > > The downside is we have had to *invent* one module name math - whose *only* > purpose is to hide the definition of fib/3 which we don't want to be made > callable. > > If we put a second function into the module math, then this second function > could call fib/3 which breaks the encapsulation of fib/3. > > We could say: > > let fib = fun(N) -> fib(N, 1, 0) end > in > fib(N, A, B) when N < 2 -> A; > fib(N, A, B) -> fib(N-1, A+B, A). > end. One reason where letrec might not be a good enough replacement for a helper function that is private to a module, is if this helper function is called from many places. I wouldn't want to have to repeat its definition every time I need it... I also feel like Mazen that unless there is a big shift in the way we think about the programs, the problem will still be present at the prefix level. If there is to be a big shift in the paradigms, then the question is whether the result will still be Erlang... regards, Vlad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.henoch@REDACTED Tue May 24 11:02:17 2011 From: magnus.henoch@REDACTED (Magnus Henoch) Date: Tue, 24 May 2011 09:02:17 +0000 (GMT) Subject: [erlang-questions] System timers, now/0, and instrumentation In-Reply-To: Message-ID: <673380092.213661306227737701.JavaMail.root@zimbra> ----- "Amy Lear" wrote: > The issue here as I understand it is that the system clock itself > can't report things in the microsecond range (msdn states the > granularity is between 10ms and 15ms: > http://msdn.microsoft.com/en-us/library/system.datetimeoffset.utcnow.aspx > ), but the real values are being mangled to provide those guaranteed > unique values. Given that now/0 is the obvious means of doing > measurement for an erlang user -- and in fact the instrumentation > tools that ship with erlang also appear to rely on it -- this results > in puzzling and undesired behavior. Have you tried os:timestamp/0? It's like now/0 but without the uniqueness guarantee. I'm not sure what granularity it has on Windows, though. Hope this helps, -- Magnus Henoch Erlang Solutions Ltd http://www.erlang-solutions.com/ From krab@REDACTED Tue May 24 11:05:03 2011 From: krab@REDACTED (Kresten Krab Thorup) Date: Tue, 24 May 2011 11:05:03 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: <4AA969E9-93F7-4E0F-8C36-E784D83F3F18@trifork.com> Sorry, my mail got strangled in flight. Here we go again... in plain text. The gen_server module is used for three different things: - as a collection of API function (left) - a place to put the code that controls the gen_server process (middle) - a place to describe the abstract notion of a gen_server behavior (right). Ideally, I think those three usages should be separate language constructs, but probably not in separate files (or other kinds of units). When using a gen_server, it would be nice if you did not have to expose the behavior api to the "user" of your module. Currently, the module is the unit of code loading. I think we could use a bette mechanism, perhaps one that supports an STM-like thing in the VM to control the loading of a set of modules. I don't have much deep experience with code loading in Erlang (but do have it on Java), and it just seems to me that being able to control atomic loading of .. say a new version of an Erlang application would be good to have supported in the VM. Gilad Bracha (who's working on Newspeak) has an excellent blog on new notions of modues that you should read. You can start here http://gbracha.blogspot.com/2009/06/ban-on-imports.html One of the things he's arguing is that modules should be VALUES. A "module" in newspeak is kind of a template (function), which take other module instances as arguments. So you hook up a system by applying such templates (possibly using letrec). If we had a visual programming environment, then many things don't need a name. Self is an example of this (Self, the video: http://video.google.com/videoplay?docid=5776880551404953752#) Kresten From xiaopong.tran@REDACTED Tue May 24 11:31:18 2011 From: xiaopong.tran@REDACTED (Xiaopong Tran) Date: Tue, 24 May 2011 17:31:18 +0800 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: <4DDB7AE6.4050204@gmail.com> On 05/24/2011 04:49 PM, Josh Johnston wrote: > > > In a normal language this would be a problem, but in erlang we can get > the desired behaviour by using pattern matching, right? > > So instead of > > > to_html() > resource_exists() > etc > > > We have > > resource(to_html, ...) > resource(exists, ...) > etc > > I'm not disagreeing with you - we do need some good way to do this. But > I don't think modules are necessary in this case. > Pattern matching might work here, but do away with modules and using pattern matching would a heavier load on the programmer. Modules or not, it does not have much effect on the VM, we can just make the VM work without modules. But I think programmers would have to work harder, distinguishing which function is which. Although I don't really like the Erlang module, but I think it's better with it than without. Xiaopong From octopusfluff@REDACTED Tue May 24 11:32:47 2011 From: octopusfluff@REDACTED (Amy Lear) Date: Tue, 24 May 2011 02:32:47 -0700 Subject: [erlang-questions] System timers, now/0, and instrumentation In-Reply-To: <673380092.213661306227737701.JavaMail.root@zimbra> References: <673380092.213661306227737701.JavaMail.root@zimbra> Message-ID: On Tue, May 24, 2011 at 2:02 AM, Magnus Henoch < magnus.henoch@REDACTED> wrote: > ----- "Amy Lear" wrote: > > > The issue here as I understand it is that the system clock itself > > can't report things in the microsecond range (msdn states the > > granularity is between 10ms and 15ms: > > > http://msdn.microsoft.com/en-us/library/system.datetimeoffset.utcnow.aspx > > ), but the real values are being mangled to provide those guaranteed > > unique values. Given that now/0 is the obvious means of doing > > measurement for an erlang user -- and in fact the instrumentation > > tools that ship with erlang also appear to rely on it -- this results > > in puzzling and undesired behavior. > > Have you tried os:timestamp/0? It's like now/0 but without the > uniqueness guarantee. I'm not sure what granularity it has on > Windows, though. > > Hope this helps, > Unfortunately, it appears that the granularity of os:timestamp/0 is no finer than 1 ms, and the minimum resolution appears to be machine-dependant. Msdn research also suggests that the 1ms resolution timer is slower to access than the normal system clock, which could matter in some circumstances. Conversely, dropping the uniqueness facet and being higher resolution than now/0 does have some potential usefulness, but the erlang documentation indicates that the provided profiling tools rely on now/0. My question about instrumentation stands: is there currently a way to do high resolution profiling in Erlang on Windows? Is the requisite work of setting up sub-ms resolution timers simply not done/too much work to attempt? -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam@REDACTED Tue May 24 11:32:52 2011 From: adam@REDACTED (Adam Lindberg) Date: Tue, 24 May 2011 11:32:52 +0200 Subject: [erlang-questions] Mocking I/O calls - defining sequence of returns In-Reply-To: References: <312F7919-F0D3-4BDB-AA0F-73951D42209A@gmail.com> Message-ID: <4DDB7B44.8030801@erlang-solutions.com> Hi, Spurred by the discussion, I did take a look at implementing this in meck. There are a few alternatives to simulating state in mocks: * Using the process dictionary - Pros: fast, simple, easy to understand - Cons: not "thread safe", no transactions * Implement your own state in another process, used by the mock - Pros: fast, simple - Cons: can be made specific for the test case and thus needs less locking * Keeping state in the actual mock (a process in meck's case) - Pros: Can be made "thread safe" - Cons: slow (will lock process for each call to mock) You cannot do a mock with fun() -> timer:sleep(infinity) end, for example. The latter means that for a test program to be able to manipulate the mock (add expectations or get history) no code must be using the mock (since the mock process is blocked for the duration of the call to the mock, to be able to guarantee transactional state changes). I did a reference implementation of this and it got a bit messy in a few different edge scenarios, but it works. I did implement the synchronized state which has the cons described above. A simpler earlier version which I tested first had a much neater implementation but did not synchronize puts/gets between calls (similar to using the process dictionary, except that it was using the dictionary of the mock process instead). You can check out the latest implementation here: https://github.com/eproxus/meck/tree/put-get The branch adds meck:put/2 and meck:get/1 to be used inside mocks. A new option can be passed to meck:new/2 which initializes the dictionary: meck:new(mymod, [{dict, {a, 0}}]), meck:expect(mymod, test, fun() -> meck:put(a, meck:get(a) + 1) end), 0 = mymod:test(), 1 = mymod:test(), 2 = mymod:test(), % etc You can see the "breakage" created by looking at the uncommented test case. Performance has not been looked at at all. Cheers, Adam Tim Watson wrote: > On 23 May 2011 10:51, Dmitry Demeshchuk wrote: >> You can use meck and process dictionary combination, for example: > > That's a bit dangerous if the module under test gets called from > multiple processes though, which is often (perhaps even normally?) the > case. For very simple cases it might be ok though, as you say. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From mazen.harake@REDACTED Tue May 24 11:44:56 2011 From: mazen.harake@REDACTED (Mazen Harake) Date: Tue, 24 May 2011 11:44:56 +0200 Subject: [erlang-questions] Erlang gen_fsm transition to a new state In-Reply-To: References: Message-ID: If you start a gen_fsm init() will be called init() -> {ok, foo, undefined}. Next message you send with send_event() to the gen_fsm will be handled by foo() foo(_, _) -> {next_state, bar, undefined}. Next message will be handled by bar() bar(_, _) -> {next_state, foo, undefined). Next message will be handled by foo(). If you use sync_send_event() instead then these functions must be of arity 3 since you get a "From" variable with them. so, yes you can mix them but they are called differently. And don't use a sync_send_event() from inside a callback function because you will deadlock. /M On 24 May 2011 10:45, Alexander Kuleshov wrote: > Can i have any state_name/3 || /2 functions with different names? > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Tue May 24 11:46:08 2011 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Tue, 24 May 2011 11:46:08 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: <4AA969E9-93F7-4E0F-8C36-E784D83F3F18@trifork.com> References: <4AA969E9-93F7-4E0F-8C36-E784D83F3F18@trifork.com> Message-ID: On Tue, May 24, 2011 at 11:05, Kresten Krab Thorup wrote: > > One of the things he's arguing is that modules should be VALUES. ?A "module" in newspeak is kind of a template (function), which take other module instances as arguments. ?So you hook up a system by applying such templates (possibly using letrec). > This is a great idea. Why? Because it is the path of existential types :-) Notice that in Erlang, a module is a Value. It is possible to call Mod:Fun(..). Second, notice that the parameterized module extension allows us to parameterize a module over some other module. Specifically we could have -module(RBTree, [OrderMod]). where OrderMod is a module which has a function -opaque t() :: ..... -export_type([t/0]). -spec order(t(), t()) -> lt | eq | gt. and so we have generalized our RedBlack trees to be able to use any ordering relation, not simply the one that is built it. The style Gilad is advocating is the "Fully functorial style" from the Standard ML community. A Functor[1] in SML terminology is a function from module to module ("functor" stems from category theory where it designates a "function"[2] one level up). In the style, you build up programs by stitching together smaller modularized parts building larger and larger modules in the process. Example: The gen_server is a functor from a module (which obeys the gen_server behaviour and has handle_* functions) to a specific instance of a server. It also gives you quite the path towards the concept of OOP, as can be observed from the parameterized module extension and its uses in various places. In languages with static types, you can of course enforce that functor applications are type-correct. If you allow modules as values in such languages you get existential types which is a way to get something OOP-like into those languages[3]. So after a little tour around: Erlang already has this :P Modules are an essential part of building large systems. The very notion that you can pack up functions in a module and ship them as a unit is quite important. Also the notion you can replace a module-component at once. I feel that the problem of function placement in the right module is less of a problem compared to the hell it would be with one large global namespace. And it is much more than just a "bunch of functions thrown together". Specifically, modules allows me to have an *abstract* view of a data structure. In the above, I have no idea what t() is. I am only allowed to compare two t()'s to each other with OrderMod:compare(T1, T2). That is, the only algebraic operation I am allowed to do is this. Other parts of the program may have a different view of t() and be able to do more with it, but to me, it is an opaque term. It matters because someone can go replace t(), and my code does not have to be changed at all. This is impossible if t() leaks. And I am grateful the dialyzer can find places where it is leaking. Likewise, a module can hide the fact it is implemented with a gen_server. So I can go replace it with a gen_fsm, and nobody has to alter their code because the API i exported was exactly the API I will keep stable. Processes componentize the heap. Modules componentize the code. [1] Beware of connotating the word functor in programming with something specific in computer science. The meaning is different in Standard ML, in Haskell and in C++. [2] I am lying. The basic notion is a morphism of which the function is a special case when considering the category of Sets. [3] I still don't get why you can't use static typing in Erlang. The conservative approach is simply to use polymorphic variants for all message passing and it would essentially work right out of the bat. -- J. From amphibian.ltd@REDACTED Tue May 24 12:03:53 2011 From: amphibian.ltd@REDACTED (Tim Carpenter) Date: Tue, 24 May 2011 11:03:53 +0100 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: <4AA969E9-93F7-4E0F-8C36-E784D83F3F18@trifork.com> References: <4AA969E9-93F7-4E0F-8C36-E784D83F3F18@trifork.com> Message-ID: <85A6B8FA-31FF-4D59-9AC0-A55C14B2366B@gmail.com> Hi all, I am sticking to the request to not comment on other solutions but present my own thoughts... 1. Some units of code only make sense as a collection. who would use part of gen_server in isolation? Well, you could,but to have it separate exposes it to modification that could distort the focused purpose of the unit. 2. some functions have intentionally hidden aspects, private calls etc and these again are best left hidden or considered as a logical whole otherwise side effects or bloat may occur. 3. I see no reason why we cannot logically group functions into modules but not have the code in there...i.e. the module contains the references to functions that make it up. this allows logical handling of groups of functions for code management and can allow one function to appear in multiple modules without code duplication. it also allows one to add/delete/replace a function in a module knowing that the source code for the other functions have not been touched! 4. naming conventions should be given great thought for simplicity and intuitiveness. functions could be in n sets, so a strict hierarchy may not suit. 5. if functions are named as being in modules, the need to provide abstraction to the full name may be advantageous, so modulename.sort/3 can be used and the module definition translates this to a unique longhand which can change over time. The programmer should also be able to use the longhand at will using the module as a convenient bulk import/compile vehicle that will break at compile time (one would hope). Some form of 'expects...' notation could allow a form of protection against inadvertent swapping of functions in shared modules altering behaviour. 6. we may want 3 elements to naming of functions: shorthand, longhand, and version, so one can use the latest version of a longhand named function, lock to a specific version of a longhand named function or use the shorthand latest version or other such combinations. 7. n- tier modules - modules of modules? possibly. Tim On 24 May 2011, at 10:05, Kresten Krab Thorup wrote: > Sorry, my mail got strangled in flight. Here we go again... in > plain text. > > The gen_server module is used for three different things: > > - as a collection of API function (left) > - a place to put the code that controls the gen_server process > (middle) > - a place to describe the abstract notion of a gen_server behavior > (right). > > Ideally, I think those three usages should be separate language > constructs, but probably not in separate files (or other kinds of > units). > > When using a gen_server, it would be nice if you did not have to > expose the behavior api to the "user" of your module. > > > Currently, the module is the unit of code loading. I think we could > use a bette mechanism, perhaps one that supports an STM-like thing > in the VM to control the loading of a set of modules. I don't have > much deep experience with code loading in Erlang (but do have it on > Java), and it just seems to me that being able to control atomic > loading of .. say a new version of an Erlang application would be > good to have supported in the VM. > > > Gilad Bracha (who's working on Newspeak) has an excellent blog on > new notions of modues that you should read. You can start here http://gbracha.blogspot.com/2009/06/ban-on-imports.html > > One of the things he's arguing is that modules should be VALUES. A > "module" in newspeak is kind of a template (function), which take > other module instances as arguments. So you hook up a system by > applying such templates (possibly using letrec). > > > If we had a visual programming environment, then many things don't > need a name. Self is an example of this (Self, the video: http://video.google.com/videoplay?docid=5776880551404953752#) > > Kresten > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions Tim Carpenter Amphibian Ltd London ENGLAND +44(0)7900 888826 amphibian.ltd@REDACTED From gary@REDACTED Tue May 24 12:19:59 2011 From: gary@REDACTED (Gary Hai) Date: Tue, 24 May 2011 18:19:59 +0800 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: I am working on state-oriented programming model, and I have the same question as you. In the view of SOP, erlang process is a FSM, and suitable granularity of functions as states. The finite set of states of a FSM just like erlang module, but it always cross modules boundaries. So in SOP model, the module concept has been very vague, just for unique distinct name of function. The model of a state activity is a function as bellow: act(Entity, Input) -> {ok, Output} | {ok, Output, UpdatedEntity} | {error, Error} | {stop, Output, Entity} The output of the state may be {NextState, Output}. The NextState may be the next state activity function or just a directive of next state. Then FSM engine matches the directive to a state activity then transfers the previous state to the new state with the previous output as input. The state activity function may be from anywhere, function in a module, binary loaded from database, code dynamically generated by JIT. -------- Gary Hai On May 24, 2011, at 4:06 PM, Joe Armstrong wrote: > Why do we need modules at all? > > This is a brain-dump-stream-of-consciousness-thing. I've been > thinking about this for a while. > > I'm proposing a slightly different way of programming here > The basic idea is > > - do away with modules > - all functions have unique distinct names > - all functions have (lots of) meta data > - all functions go into a global (searchable) Key-value database > - we need letrec > - contribution to open source can be as simple as > contributing a single function > - there are no "open source projects" - only "the open source > Key-Value database of all functions" > - Content is peer reviewed > > These are discussed in no particular order below: > > Why does Erlang have modules? > > There's a good an bad side to modules: > > Good: Provides a unit of compilation, a unit of code > distribution. unit of code replacement > > Bad: It's very difficult to decide which module to put an individual > function in. Break encapsulation (see later) > > Aside: lib_misc.erl > > When I'm programming I often get to the point were I say there should > a function foo/2 in lists.erl but their isn't. There should be but > there isn't - foo/2 is a small self contained thing. Why should it be > in lists.erl because it "feels right". > > Strings are lists, so why do we have two modules lists.erl and > string.erl how should I decide in which module my new string/list > processing function should go. > > To avoid all mental anguish when I need a small function that > should be somewhere else and isn't I stick it in > a module elib1_misc.erl. > > My elib1_misc exports the following: > > added_files/2 make_challenge/0 > as_bits/1 make_response/2 > as_bits_test/0 make_response_test/0 > bdump/2 make_test_strings/1 > bin2hex/1 make_test_strings_test/0 > bin2hex_test/0 make_tmp_filename/2 > check_io_list/1 merge_kv/1 > collect_atom/1 merge_kv_test/0 > collect_atom_test/0 mini_shell/0 > collect_int/1 module_info/0 > collect_int_test/0 module_info/1 > collect_string/1 ndots/1 > collect_string_test/0 nibble_to_hex_char/1 > collect_word/1 nibble_to_hex_char_test/0 > complete/2 odd/1 > complete_test/0 on_exit/2 > dos2unix/1 out_of_date/2 > downcase_char/1 outfile/2 > dump/2 padd/2 > dump_tmp/2 perms/1 > duplicates/1 perms_test/0 > ensure_started/2 pmap/2 > eval_file/1 pmap1/2 > eval_file_test/0 pmap1_test/0 > eval_string/1 pmap_test/0 > eval_string_test/0 priority_receive/0 > every/3 random_seed/0 > expand_env_vars/1 random_string/1 > expand_file_template/3 random_string/2 > expand_string_template/2 read_at_most_n_lines/2 > expand_tabs/1 read_at_most_n_lines_test/0 > expand_tabs_test/0 remove_duplicates/1 > expand_template/2 remove_duplicates_test/0 > extract_attribute/2 remove_leading_and_trailing_whitespace/1 > extract_attribute_test/0 remove_leading_and_trailing_whitespace_test/0 > extract_prefix/2 remove_leading_whitespace/1 > fetch/2 remove_prefix/2 > fetch_test/0 remove_prefix_test/0 > file2lines/1 remove_trailing_whitespace/1 > file2lines_test/0 replace/3 > file2md5/1 root_dir/0 > file2numberedlines/1 rpc/2 > file2numberedlines_test/0 safe/1 > file2paras/1 show_loaded/1 > file2stream/1 signed_byte_to_hex_string/1 > file2string/1 signed_byte_to_hex_string_test/0 > file2template/1 skip_blanks/1 > file2term/1 skip_blanks_test/0 > file_size_and_type/1 skip_to_nl/1 > find_src/1 skip_to_nl_test/0 > first/1 sleep/1 > flatten_io_list/1 spawn_monitor/3 > flush_buffer/0 split_at_char/2 > for/3 split_at_char_test/0 > force/1 split_list/2 > foreach_chunk_in_file/3 split_list_test/0 > foreach_word_in_file/2 string2exprs/1 > foreach_word_in_string/2 string2exprs_test/0 > forever/0 string2html/1 > get_erl_section/2 string2latex/1 > get_line/1 string2lines/1 > get_line/2 string2lines_test/0 > have_common_prefix/1 string2stream/1 > have_common_prefix_test/0 string2stream_test/0 > hex2bin/1 string2template/1 > hex2bin_test/0 string2template_test/0 > hex2list/1 string2term/1 > hex2list_test/0 string2term_test/0 > hex_nibble2int/1 string2toks/1 > hex_nibble2int_test/0 string2toks_test/0 > id/1 sub_binary/3 > include_dir/0 template2file/3 > include_file/1 term2file/2 > interleave/2 term2string/1 > is_alphanum/1 test/0 > is_blank_line/1 test1_test/0 > is_prefix/2 test_function_over_substrings/2 > is_prefix_test/0 tex2pdf/1 > is_response_correct/3 time_fun/2 > keep_alive/2 time_stamp/0 > lines2para/1 to_lower/1 > list2frequency_distribution/1 to_lower_test/0 > list2frequency_distribution_tetrim/1 > longest_common_prefix/1 trim_test/0 > longest_common_prefix_test/0 unconsult/2 > lookup/2 unsigned_byte_to_hex_string/1 > lorem/1 unsigned_byte_to_hex_string_test/0 > ls/1 which/1 > which_added/1 > > Now I find this very convenient when I write a new small utility function > I stick in in elib1_misc.erl - no mental anguish in choosing a module > name is involved. > > The observation that I find this very-convenient is telling me something > about modules - I like my elib1_misc it feels right. > > (aside - It seems many development projects have their own private > lib_miscs ...) > > Which brings me to the point of my question. > > Do we need module's at all? Erlang programs are composed of lots of small > functions, the only place where modules seem useful is to hide a letrec. > > The classic example is fibonacci. We want to expose fib/1 but hide the > helper function fib/3. Using modules we say > > -module(math). > -export([fib/1]). > > fib(N) -> > fib(N, 1, 0). > > fib(N, A, B) when N < 2 -> A; > fib(N, A, B) -> fib(N-1, A+B, A). > > The downside is we have had to *invent* one module name math - whose *only* > purpose is to hide the definition of fib/3 which we don't want to be made > callable. > > If we put a second function into the module math, then this second function > could call fib/3 which breaks the encapsulation of fib/3. > > We could say: > > let fib = fun(N) -> fib(N, 1, 0) end > in > fib(N, A, B) when N < 2 -> A; > fib(N, A, B) -> fib(N-1, A+B, A). > end. > > I hardly dare suggest a syntax for this since I've been following > another thread in this forum where syntax discussion seem to encourage > much comment. > > ** Please do suggest alternative syntax's here - but do not comment on > other peoples suggestions ... > > I would like to just talk about why we have modules. > > Another question: > > Does the idea of a module come from the idea that functions have to be > stored somewhere, so we store them in a file, and we slurp the > file (as a unit) into the system, so the file becomes a module? > > If all the files were store by themselves in a database would this > change things. > > I am thinking more and more that if would be nice to have *all* functions in > a key_value database with unique names. > > lookup(foo,2) would get the definition foo foo/2 from a database. > > The unique names bit is interesting - is this a good idea. Qualified > names (ie names like xxx:foo/2) or (a.b.c.foo/2) sounds like a good > idea but but when I'm programming I have to invent the xxx or the > a.b.c which is very difficult. It also involves the "decision problem" > if the namespaces xxx and a.b.c already exist I have to *choose* which > to put my new function in. > > I think there might be a case for alises here joe:foo/2 could be used > while developing "joe" would expand to a horrible random local string the > real name being ab123aZwerasch123123_foo/2 but I would not be able to > publish my code or make it available to a third_part before I had > chosen a sensible name. > > (( managing namespaces seems really tricky, a lot of peoople seem > to thing that the problem goes away by adding "." 's to the name > but managing a namespace with namees like foo.bar.baz.z is just as complex > as managing a namespace with names like foo_bar_baz_z or names like > 0x3af312a78a3f1ae123 - the problem is that we have to go from a symbolic > name like www.a.b to a reference like 123.45.23.12 - but how do we discover > the initial name www.a.b? - there are two answers - a) we are given the name > (ie we click on a link) - we do not know the name but we search fo it )) > > > When programs are small we can live with "just the code" in "a few > modules" the ratio of code to meta data is high. > > When programs are large we need a lot of meta-data to understand them. > > I would like to see all functions with all meta-data in a data base. > > I'd like to say: > > lookup(foo,2,Attribute) when Attribute = > > code|source|documentation|type signatures|revision history|authors|... > > The more I think about it the more I think program development should > viewed as changing the state of a Key-Value database. > > So I imagine: > > 1) all functions have unique names > 2) there are no modules > 3) we discover the name of a function by searching metadata > describing the function in a database > 4) all public functions (think open source) are in the same > database > > We could make a system to do this. > > I think this would make open-source projects easier, since the > granularity of contribution goes down. You could contribute > a single function - not an entire application. > > (( A problem with GUT style open source projects is there is > not one database of functions, I often what one function from > this project, another function from another project -- the > granularity of reusable parts should be the individual function. > > functions are really easy to reuse > modules are more difficult to reuse > entire applications are very difficult to reuse > (Unless there are isolated through a communication channel)) > > Possible extensions. > > 1) Voting for promotion > 2) A review process > > Given a raw database will *all* functions in it - we could derive an > "approved" functions database. > > Popular functions could be moved to the approved database - the > review process would need to be discussed - so kind of peer-review/wiki > stuff. > > Comments? > > Volunteers? > > /Joe > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From jesper.louis.andersen@REDACTED Tue May 24 12:26:51 2011 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Tue, 24 May 2011 12:26:51 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: On Tue, May 24, 2011 at 10:06, Joe Armstrong wrote: > Why do we need modules at all? I think we need modules, but this post sparked a thought I have had for some time now. I'd like to have module renaming/namespacing! Specifically, I want a mechanism by which I can clean up the naming mess in the stdlib without affecting old programs. That is, I want to be able to, at an application/module level, rename function calls in a way such a way that can clean up parameter orders and so on. I don't care about how the solution is. I am after the goal: Cleaning up the stdlib mess. You may argue this is a messy thing, but I think it is a necessity if you want to move the standard library on: * We can't alter existing functions because people rely on them. * Existing functions are not consistent. This is a social deadlock I want to break. In fact it is a deadlock I think we can only break if we allow the coexistence of more than one module with the same name (but stemming from different namespaces). I don't want nesting. Just two levels, so I can say -use_namespace(v2_modules). in modules which use version two of the stdlib in which things are sensibly named. At some point you can then flip around and compile old code with a compatibility layer. -- J. From bengt.kleberg@REDACTED Tue May 24 12:39:18 2011 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Tue, 24 May 2011 12:39:18 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: <1306233558.4959.61.camel@seasc1137> Greetings, It would be very nice to have module renaming/namespacing that allowed me to do the following: The modules "misc_lib" and "misc_lib_helper" from developer A should be able to call each other with their original names. The modules "misc_lib" and "misc_lib_helper" from developer B should be able to call each other with their original names. I should be able to call all 4 at the same time with names that I have create/renamed. So, I need to load modules as a set/application/??? that renames them outside of that set (it would be ok to have the same prefix added to all of them), and still allows the files in the set/application/??? to keep using to the old names. When it comes to improving stdlibs I suggest that we create new, better modules. Keep the old ones (for ever?) but print a big "deprecated" all over the man pages. bengt On Tue, 2011-05-24 at 12:26 +0200, Jesper Louis Andersen wrote: > On Tue, May 24, 2011 at 10:06, Joe Armstrong wrote: > > Why do we need modules at all? > > I think we need modules, but this post sparked a thought I have had > for some time now. > > I'd like to have module renaming/namespacing! > > Specifically, I want a mechanism by which I can clean up the naming > mess in the stdlib without affecting old programs. That is, I want to > be able to, at an application/module level, rename function calls in a > way such a way that can clean up parameter orders and so on. I don't > care about how the solution is. I am after the goal: Cleaning up the > stdlib mess. > > You may argue this is a messy thing, but I think it is a necessity if > you want to move the standard library on: > > * We can't alter existing functions because people rely on them. > * Existing functions are not consistent. > > This is a social deadlock I want to break. In fact it is a deadlock I > think we can only break if we allow the coexistence of more than one > module with the same name (but stemming from different namespaces). I > don't want nesting. Just two levels, so I can say > > -use_namespace(v2_modules). > > in modules which use version two of the stdlib in which things are > sensibly named. At some point you can then flip around and compile old > code with a compatibility layer. > > From watson.timothy@REDACTED Tue May 24 13:19:27 2011 From: watson.timothy@REDACTED (Tim Watson) Date: Tue, 24 May 2011 12:19:27 +0100 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: My 2 pennies worth: I don't think getting rid of modules is a good plan. Having global (mangled) names is a path to misery. In the languages that do mess with names (python, C++, etc) it creates a bloody nightmare. I would steer clear of this. I like the idea of having a global database of code, but not all of it floating in some etherial top level namespace. Most of what's cool about http://www.haskell.org/hoogle/ and http://hackage.haskell.org/packages/hackage.html is made possible by the combination of good standardised build tools and hosting repositories, so I'd be more included to focus on improving (and extending) things like rebar and agner/erlware to provide the same kind of developer-experience without changing the language so much. Introducing letrec is a bloody marvelous suggestion. Also making it easier to do partial application and function composition would simplify a lot of the re-use cases without messing with the module system. I'm not going to stray off too far into alternative-solution land, but given the OTP team reads this list, I don't want to miss the opportunity to mention some minor things about the module system that could do with an overhaul. - Fully supported parameterised modules Not because I want to use them as a state bag, but rather that they make it easy to implement something akin to a functor without having to reside in a process. This means that all the tools need to support this concept and it is documented, etc. Extending the module system so that you can -extend a module to create a new concrete implementation would be useful: %% finder.erl -module(finder). -functor([M]). -compile(export_all). find() -> walk(fun M:match/3). %% rx_finder.erl -module(rx_finder). -extends(finder, [re]). Perhaps the syntax/approach there isn't quite right, but the point I'm getting at is that what with parameterised modules and -extends, you should be able to compose stuff easily. - Better support for *import* As the quantity of code you're dealing with increases, you need to be able to import discrete units of it in simpler and more intuitive ways. I'm not exactly a fan of Java, but you can see in that world that the quantity of libraries (often open source ones) being used on any project means you simply cannot avoid having to import things (packages, classes, static methods/functions) without going mad. Although Erlang is still (thankfully) simple enough not to have this problem, I suspect as the number of projects blossoms it will eventually approach the critical mass. Also being able to support something like -import_alias(name, mod) would be quite handy, although I realise this is fairly trivial with a parse_transform. - Fully supporting packages Personally I think the __ convention that most of us follow is fine, but it does get rather tedious. Package, namespaces or nested modules are all solution that are known to work and are widely adopted by other languages. The package system in erlang works fine, but not all the tools properly support it today (cover, reltool and a few others are broken). From watson.timothy@REDACTED Tue May 24 13:21:51 2011 From: watson.timothy@REDACTED (Tim Watson) Date: Tue, 24 May 2011 12:21:51 +0100 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: <1306233558.4959.61.camel@seasc1137> References: <1306233558.4959.61.camel@seasc1137> Message-ID: On 24 May 2011 11:39, Bengt Kleberg wrote: > Greetings, > > It would be very nice to have module renaming/namespacing that allowed > me to do the following: > The modules "misc_lib" and "misc_lib_helper" from developer A should be > able to call each other with their original names. > The modules "misc_lib" and "misc_lib_helper" from developer B should be > able to call each other with their original names. > I should be able to call all 4 at the same time with names that I have > create/renamed. > > So, I need to load modules as a set/application/??? that renames them > outside of that set (it would be ok to have the same prefix added to all > of them), and still allows the files in the set/application/??? to keep > using to the old names. > > I was thinking about this in terms of some kind of special -import or -alias directive. I think it's possible to do just with a parse_transform, as long as the set can be fully determined at compile time. That last point though - therein lies the rub. App-upgrades change things, and those things can include modules. Dragons. Nuff-said. From masklinn@REDACTED Tue May 24 13:24:25 2011 From: masklinn@REDACTED (Masklinn) Date: Tue, 24 May 2011 13:24:25 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: <72FA713D-BE5A-442A-AA3D-42D22872FF7E@masklinn.net> On 2011-05-24, at 13:19 , Tim Watson wrote: > In the languages that do mess with names (python [?] As far as I know, Python never "messes with names" unless asked explicitly via the "__" prefix, which is rarely used and generally only there to avoid naming conflicts in inheritance cases. Do you have instances, besides this quite explicit one, where Python performs any name mangling? From erlang@REDACTED Tue May 24 13:25:52 2011 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 24 May 2011 13:25:52 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: <4AA969E9-93F7-4E0F-8C36-E784D83F3F18@trifork.com> Message-ID: On Tue, May 24, 2011 at 11:46 AM, Jesper Louis Andersen < jesper.louis.andersen@REDACTED> wrote: > On Tue, May 24, 2011 at 11:05, Kresten Krab Thorup > wrote: > > > > One of the things he's arguing is that modules should be VALUES. A > "module" in newspeak is kind of a template (function), which take other > module instances as arguments. So you hook up a system by applying such > templates (possibly using letrec). > > > > This is a great idea. Why? Because it is the path of existential types :-) > > Notice that in Erlang, a module is a Value. It is possible to call > Mod:Fun(..). Second, notice that the parameterized module extension > allows us to parameterize a module over some other module. > Specifically we could have > > -module(RBTree, [OrderMod]). > > where OrderMod is a module which has a function > > -opaque t() :: ..... > -export_type([t/0]). > -spec order(t(), t()) -> lt | eq | gt. > > and so we have generalized our RedBlack trees to be able to use any > ordering relation, not simply the one that is built it. > > The style Gilad is advocating is the "Fully functorial style" from the > Standard ML community. A Functor[1] in SML terminology is a function > from module to module ("functor" stems from category theory where it > designates a "function"[2] one level up). In the style, you build up > programs by stitching together smaller modularized parts building > larger and larger modules in the process. > > Example: The gen_server is a functor from a module (which obeys the > gen_server behaviour and has handle_* functions) to a specific > instance of a server. > > It also gives you quite the path towards the concept of OOP, as can be > observed from the parameterized module extension and its uses in > various places. > > In languages with static types, you can of course enforce that functor > applications are type-correct. If you allow modules as values in such > languages you get existential types which is a way to get something > OOP-like into those languages[3]. > > So after a little tour around: Erlang already has this :P > > Modules are an essential part of building large systems. The very > notion that you can pack up functions in a module and ship them as a > unit is quite important. Also the notion you can replace a > module-component at once. I feel that the problem of function > placement in the right module is less of a problem compared to the > hell it would be with one large global namespace. And it is much more > than just a "bunch of functions thrown together". > > Specifically, modules allows me to have an *abstract* view of a data > structure. In the above, I have no idea what t() is. I am only allowed > to compare two t()'s to each other with OrderMod:compare(T1, T2). That > is, the only algebraic operation I am allowed to do is this. Other > parts of the program may have a different view of t() and be able to > do more with it, but to me, it is an opaque term. It matters because > someone can go replace t(), and my code does not have to be changed at > all. This is impossible if t() leaks. And I am grateful the dialyzer > can find places where it is leaking. > > Likewise, a module can hide the fact it is implemented with a > gen_server. So I can go replace it with a gen_fsm, and nobody has to > alter their code because the API i exported was exactly the API I will > keep stable. > > Processes componentize the heap. > Modules componentize the code. > > If we think of modules as containers of functions, then a module is a "set of functions" - my problem is with granularity. The smallest unit of reuse is the module. Suppose my application want just one function from a particular module - I'm forced to load the entire module. This hampers reuse - I *often* read library code and find a single function and cut-and-paste it into my new code. It also discourages sharing - since the smallest unit I can share is a module. The unit of distribution is an application - a set of modules - why this could not be a list of functions I do not know. I think I'd like to view an application as something that offered a message based service that internally was constructed from a set of functions rather than a set of modules. /Joe > > > [1] Beware of connotating the word functor in programming with > something specific in computer science. The meaning is different in > Standard ML, in Haskell and in C++. > > [2] I am lying. The basic notion is a morphism of which the function > is a special case when considering the category of Sets. > > [3] I still don't get why you can't use static typing in Erlang. The > conservative approach is simply to use polymorphic variants for all > message passing and it would essentially work right out of the bat. > > -- > J. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Tue May 24 13:28:53 2011 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 24 May 2011 13:28:53 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: On Tue, May 24, 2011 at 12:26 PM, Jesper Louis Andersen < jesper.louis.andersen@REDACTED> wrote: > On Tue, May 24, 2011 at 10:06, Joe Armstrong wrote: > > Why do we need modules at all? > > I think we need modules, but this post sparked a thought I have had > for some time now. > > I'd like to have module renaming/namespacing! > I agree - I still like the good 'ol Knuthian way - start with source file, then add patch files. You could make a language could make a language construct for this. new_foo = alias foo/2 > > Specifically, I want a mechanism by which I can clean up the naming > mess in the stdlib without affecting old programs. That is, I want to > be able to, at an application/module level, rename function calls in a > way such a way that can clean up parameter orders and so on. I don't > care about how the solution is. I am after the goal: Cleaning up the > stdlib mess. > > You may argue this is a messy thing, but I think it is a necessity if > you want to move the standard library on: > > * We can't alter existing functions because people rely on them. > * Existing functions are not consistent. > > This is a social deadlock I want to break. In fact it is a deadlock I > think we can only break if we allow the coexistence of more than one > module with the same name (but stemming from different namespaces). I > don't want nesting. Just two levels, so I can say > > -use_namespace(v2_modules). > > in modules which use version two of the stdlib in which things are > sensibly named. At some point you can then flip around and compile old > code with a compatibility layer. > > > -- > J. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Tue May 24 13:46:17 2011 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 24 May 2011 13:46:17 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: <1306233558.4959.61.camel@seasc1137> Message-ID: On Tue, May 24, 2011 at 1:21 PM, Tim Watson wrote: > On 24 May 2011 11:39, Bengt Kleberg wrote: > > Greetings, > > > > It would be very nice to have module renaming/namespacing that allowed > > me to do the following: > > The modules "misc_lib" and "misc_lib_helper" from developer A should be > > able to call each other with their original names. > > The modules "misc_lib" and "misc_lib_helper" from developer B should be > > able to call each other with their original names. > > I should be able to call all 4 at the same time with names that I have > > create/renamed. > > > > So, I need to load modules as a set/application/??? that renames them > > outside of that set (it would be ok to have the same prefix added to all > > of them), and still allows the files in the set/application/??? to keep > > using to the old names. > > > > > > I was thinking about this in terms of some kind of special -import or > -alias directive. I think it's possible to do just with a > parse_transform, as long as the set can be fully determined at compile > time. That last point though - therein lies the rub. App-upgrades > change things, and those things can include modules. Dragons. > Nuff-said. > It depends upon what -import means. -import(foo, [bar/2 ]). Where are two interpretations a) "when you *run* this program and find a call to foo:bar/2 go and see if you can find the code for foo, load it then call the function bar/2" b ) "When you *compile* this program find the code for foo:bar/2 and extract the code for bar/2 and include it in my code" - in this case you resolve the name at compile time. I guess when developing a) is useful but when you deploy code it should be b) /Joe > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From watson.timothy@REDACTED Tue May 24 13:50:03 2011 From: watson.timothy@REDACTED (Tim Watson) Date: Tue, 24 May 2011 12:50:03 +0100 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: > Now I find this very convenient when I write a new small utility function > I stick in in elib1_misc.erl - no mental anguish in choosing a module > name is involved. But it's not very helpful to someone else who's going to have to mentally parse your lib_misc library to figure out what they're looking for. It does sound a bit like a dumping ground. > > The observation that I find this very-convenient is telling me something > about modules - I like my elib1_misc it feels right. > > (aside - It seems many development projects have their own private > lib_miscs ...) Perhaps if those libraries were broken into their constituent parts and then those into their constituent projects, they would be easier to re-use. I see the same thing on many projects - a _config.erl that wraps a gen_server with maybe some calls to application:get_env and a _log.erl and so on. I nearly wrote a erl-config package on github until I realised gproc would be a better choice for my needs. > > Which brings me to the point of my question. > > Do we need module's at all? Erlang programs are composed of lots of small > functions, the only place where modules seem useful is to hide a letrec. > I think that's an oversimplification. Compilation units (e.g., putting code in different files) is beneficial for humans first and foremost. I think that categorising functions based on subject-area and/or the process they relate too is very useful. Once you do that categorising, putting all the categories in once place is very sensible. OCaml and Haskell programmers (of which I'm only experiences with the former), use letrec (and similar concepts such as Haskell's `where`) heavily, but would not dream of doing away with our module systems just because we can encapsulate things in this way. Modules are a useful categorisation for the human mind to remember things by. Like packages, they help us remember where to look for things. They're also useful for hiding - breaking encapsulation is a choice, not something you cannot help when designing a module. > The downside is we have had to *invent* one module name math - whose *only* > purpose is to hide the definition of fib/3 which we don't want to be made > callable. > Actually if you put all your mathematical functions in this module, it would be more useful (and easier to remember). > If we put a second function into the module math, then this second function > could call fib/3 which breaks the encapsulation of fib/3. Not sure that's such a terrible thing really. > > We could say: > > let fib = fun(N) -> fib(N, 1, 0) end > in > ?? fib(N, A, B) when N < 2 -> A; > ?? fib(N, A, B) -> fib(N-1, A+B, A). > end. > Having letrec (or where) is an awesome idea. Don't actually care much about the choice of syntax - just another one to learn. > Does the idea of a module come from the idea that functions have to be > stored somewhere, so we store them in a file, and we slurp the > file (as a unit) into the system, so the file becomes a module? Probably, yes. It is convenient and familiar to do so. > > If all the files were store by themselves in a database would this > change things. > Not really, as long as the database is always available and I *never ever* run into a situation where I can't work because I'm not connected. > I am thinking more and more that if would be nice to have *all* functions in > a key_value database with unique names. I love the idea of a massive code repo/server, but having everything in one namespace sounds like a nightmare. > The unique names bit is interesting - is this a good idea. Qualified > names (ie names like xxx:foo/2) or (a.b.c.foo/2) sounds like a good > idea but but when I'm programming I have to invent the xxx or the > a.b.c which is very difficult. It also involves the "decision problem" > if the namespaces xxx and a.b.c already exist I have to *choose* which > to put my new function in. Still I think it's the right thing to do. > > I think there might be a case for alises here joe:foo/2 could be used > while developing "joe" would expand to a horrible random local string the > real name being ab123aZwerasch123123_foo/2? but I would not be able to > publish my code or make it available to a third_part before I had > chosen a sensible name. Yuk. ;) > > (( managing namespaces seems really tricky, a lot of peoople seem > to thing that the problem goes away by adding "." 's to the name > but managing a namespace with namees like foo.bar.baz.z is just as complex > as managing a namespace with names like foo_bar_baz_z or names like > 0x3af312a78a3f1ae123 - the problem is that we have to go from a symbolic > name like www.a.b to a reference like 123.45.23.12 - but how do we discover > the initial name www.a.b? - there are two answers - a) we are given the name > (ie we click on a link) - we do not know the name but we search fo it )) You're right it is hard, but it is possible. > > > When programs are small we can live with "just the code" in "a few > modules" the ratio of code to meta data is high. > > When programs are large we need a lot of meta-data to understand them. > > I would like to see all functions with all meta-data in a data base. > > I'd like to say: > > ?? lookup(foo,2,Attribute) when Attribute = > > ????? code|source|documentation|type signatures|revision history|authors|... > I like the idea of finding a function based on a wider range of attributes such as these, but not choosing the route of dispatch based on a loose predicate. Lookup/3 would have to guarantee that it will resolve to a single callee every time, which I can't see being possible. From watson.timothy@REDACTED Tue May 24 13:54:44 2011 From: watson.timothy@REDACTED (Tim Watson) Date: Tue, 24 May 2011 12:54:44 +0100 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: <1306233558.4959.61.camel@seasc1137> Message-ID: > Where are two interpretations > > a)? "when you *run* this program and find a call to foo:bar/2 go and see if > you can find the code > for foo, load it then call the function bar/2" > > b ) "When you *compile* this program find the code for foo:bar/2 and > extract the code for bar/2 and include it in my code" - in this case you > resolve the name at compile time. > > I guess when developing a) is useful but when you deploy code it should be > b) > I completely agree. I'm also quite willing to loose the convenience of (a) providing the compiler is fast enough. From max.lapshin@REDACTED Tue May 24 13:56:18 2011 From: max.lapshin@REDACTED (Max Lapshin) Date: Tue, 24 May 2011 15:56:18 +0400 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: Very strange topic for me. I'd like to know if there will be hierarchial modules in Erlang, because tree of packages is a rather good idea: erlyvideo.mpegts.encoder erlyvideo.rtp.encoder But plain module namespace is also ok. It would be impossible for me to work with 30K LOC with plain function namespace. From watson.timothy@REDACTED Tue May 24 14:05:36 2011 From: watson.timothy@REDACTED (Tim Watson) Date: Tue, 24 May 2011 13:05:36 +0100 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: > But plain module namespace is also ok. It would be impossible for me > to work with 30K LOC with plain function namespace. I think what Joe is getting at - he'll correct me if I'm wrong about this - is to refer to functions not only by name, but by other metadata as well. I'm not sure what this looks like empirically, as like you I can't see how using only function names you could work with a flat namespace. Looking up functions by other (additional) metadata such as type signature, author, date, company, category (mutiples?), pre/post conditions, safe guarantees, etc - that would work. In fact if you think about a process engine (such as BPMS solutions and the like) then process (i.e., function) is often selected dynamically based on many attributes, not just name. Just how this will work in practise as a replacement for existing (shall we say normal) way of referring to a function that is in a module, I could not say. But it is an interesting concept. Perhaps using a URI as the name and thereby being able to have multiple URIs representing the various different category-based paths to identify the function - the "aliases" could then redirect to the direct, uniquely named resource which would in turn return the function metadata (and binary code presumably). From systemio@REDACTED Tue May 24 14:30:45 2011 From: systemio@REDACTED (systemio systemio) Date: Tue, 24 May 2011 16:30:45 +0400 Subject: [erlang-questions] there is a blocking in the process evaluating the huge factorial Message-ID: Hi all, My Erlang is (Erlang R13B03 (erts-5.7.4) [smp:2:2] [rq:2] [async-threads:0]). WinXP SP1. I've found the strange behavior when i spawn the process to evaluate the huge factorial. Here is the factorial module: -module(test). -compile(export_all). fac(0) -> ??? 1; fac(N) -> ??? N * fac(N-1). Here is the Erlang Shell code: 1> Fac = fun() -> test:fac(100000) end. #Fun 2> S1 = fun()-> spawn(Fac), timer:sleep(3000), io:format("Will I am", []), spawn(Fac) end. #Fun 3> S2 = fun()-> spawn(Fac), io:format("Will I am", []), spawn(Fac) end. #Fun 4> S1(). Will I am<0.38.0> 5> S2(). Will I am<0.42.0> In my PC the fun Fac evaluates about 11 sec. If i start S1() i will see the message "Will I am" after 14 sec and it is strange as i expect it after 3 seconds. After message appeares i type "i()." and hit enter. This command is blocked and result appeares after 11 sec until second process evaluates. if i start S2() i will see the message "Will i am" immediately but i will not be able to type anything in the shell and my typing will appear after 22 sec. Also i've tested it with spawn(Node, ...) and the result is IAE same. Are these behaviors valid or do i do smth wrong? ~ Alex From erlang@REDACTED Tue May 24 14:45:29 2011 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 24 May 2011 14:45:29 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: On Tue, May 24, 2011 at 1:56 PM, Max Lapshin wrote: > Very strange topic for me. > > I'd like to know if there will be hierarchial modules in Erlang, > because tree of packages is a rather good idea: > No it's not - this has been the subject of long and heated discussion and is why packages are NOT in Erlang - many people - myself included - dislike the idea of hierarchical namespaces. The *dot* in the name has no semantics it's just a separator. The name could equally well be encoders.mpg.erlyvideo or mpg.applications.erlvideo.encoder - there is no logical way to organise the package name and it does not scale - > > erlyvideo.mpegts.encoder > erlyvideo.rtp.encoder > > But plain module namespace is also ok. It would be impossible for me > to work with 30K LOC with plain function namespace. > The English language has a flat namespace. I'd like a drink.alcoholic.beer with my food.unhealthy.hamburger and my food.unhealthy.national.french.fries I have no problem with flat beer and chips. /Joe > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Tue May 24 14:53:18 2011 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 24 May 2011 14:53:18 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: On Tue, May 24, 2011 at 2:05 PM, Tim Watson wrote: > > But plain module namespace is also ok. It would be impossible for me > > to work with 30K LOC with plain function namespace. > > I think what Joe is getting at - he'll correct me if I'm wrong about > this - is to refer to functions not only by name, but by other > metadata as well. I'm not sure what this looks like empirically, as > like you I can't see how using only function names you could work with > a flat namespace. Looking up functions by other (additional) metadata > such as type signature, author, date, company, category (mutiples?), > pre/post conditions, safe guarantees, etc - that would work. In fact > if you think about a process engine (such as BPMS solutions and the > like) then process (i.e., function) is often selected dynamically > based on many attributes, not just name. > Yes - how this would work I don't know - my Haskell friends say that searching for function by type signatures is good. What do I do today when I suspect that somebody has written some code ? 1) will it take me < ten minutes to write the code? yes - write it 2) google or ask a friend 3) this gets me to git or sowhere 4) search 5) cut-and-paste Not a good method - and this is *best practise* > > Just how this will work in practise as a replacement for existing > (shall we say normal) way of referring to a function that is in a > module, I could not say. But it is an interesting concept. Perhaps > using a URI as the name and thereby being able to have multiple URIs > representing the various different category-based paths to identify > the function - the "aliases" could then redirect to the direct, > uniquely named resource which would in turn return the function > metadata (and binary code presumably). > Something like this. Actually for development it would be great to say -import("http://a.b.c/modname", [foo/2]). this would just make an rcp to foo/2 on the remote host and save all the pain of locally installing the necessary code on my machine. /Joe > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.kleberg@REDACTED Tue May 24 15:07:08 2011 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Tue, 24 May 2011 15:07:08 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: <1306233558.4959.61.camel@seasc1137> Message-ID: <1306242428.4959.67.camel@seasc1137> Greetings, Perhaps it is possible to do parse_transform when loading, but I have only heard about this at compile time. I meant a way to load modules, not compile them. bengt On Tue, 2011-05-24 at 13:21 +0200, Tim Watson wrote: > On 24 May 2011 11:39, Bengt Kleberg wrote: > > Greetings, > > > > It would be very nice to have module renaming/namespacing that allowed > > me to do the following: > > The modules "misc_lib" and "misc_lib_helper" from developer A should be > > able to call each other with their original names. > > The modules "misc_lib" and "misc_lib_helper" from developer B should be > > able to call each other with their original names. > > I should be able to call all 4 at the same time with names that I have > > create/renamed. > > > > So, I need to load modules as a set/application/??? that renames them > > outside of that set (it would be ok to have the same prefix added to all > > of them), and still allows the files in the set/application/??? to keep > > using to the old names. > > > > > > I was thinking about this in terms of some kind of special -import or > -alias directive. I think it's possible to do just with a > parse_transform, as long as the set can be fully determined at compile > time. That last point though - therein lies the rub. App-upgrades > change things, and those things can include modules. Dragons. > Nuff-said. From fred.hebert@REDACTED Tue May 24 15:10:17 2011 From: fred.hebert@REDACTED (=?iso-8859-1?Q?Fr=E9d=E9ric_Trottier-H=E9bert?=) Date: Tue, 24 May 2011 09:10:17 -0400 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: <116CA749-0850-4A35-B580-AC71FB85C569@erlang-solutions.com> The problem of Erlang with regards to namespaces and modules goes further than just module names. In Erlang, the following units can be sharing/clashing namespaces: the process registry, ETS tables, module names, application names, shared records, etc. They're currently entirely disjoint and only held together by convention. However, any change to one of the solutions needs to somehow be reflected into the others, even if it's still by convention. IMO the basic hierarchy of Erlang seems to begin with the OTP release. The name of an OTP application will decide the prefixes used in module names, process names, table names, shared record names, etc. There is nothing to check that application names are unique except the programmer looking out for that, while xref and the compiler can help a bit with the rest. I think we can generalise OTP to have this given kind of organisation: release -> OTP applications -> [Modules, Tables, Shared Records, Processes] An application itself wouldn't have to worry about namespaces (if we forget included applications). The namespace problem comes at the release stage or if we're developing entirely outside of OTP, still using applications or their equivalent. To me, this makes it feel like namespace management/giving aliases and replacement of values should be managed from the release point of view, but I can't offer any suggestions as to how this could take place without relying on file renaming and strict use of ?NAMESPACE-like macros throughout the code. Nothing easily backwards compatible, and nothing to help people who are not using releases though. This in no way would solve Joe's problem with being undecided as to where functions should go, but I think getting rid of modules altogether in Erlang wouldn't be doable because of the other dependencies. In places like Javascript (client-side) or schemes without good module functionality, you pretty much just include the files and people then tend to wrap everything in functions or objects to provide an ad-hoc equivalent to namespaces or modules. I can see this behaviour emerging if Erlang were to go that way. -- Fred H?bert http://www.erlang-solutions.com From attila.r.nohl@REDACTED Tue May 24 15:11:59 2011 From: attila.r.nohl@REDACTED (Attila Rajmund Nohl) Date: Tue, 24 May 2011 15:11:59 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: 2011/5/24, Joe Armstrong : [...] > What do I do today when I suspect that somebody has written some code ? > > > 1) will it take me < ten minutes to write the code? > yes - write it > 2) google or ask a friend > 3) this gets me to git or sowhere > 4) search > 5) cut-and-paste > > Not a good method - and this is *best practise* This only works if the function in itself useful. Somehow I don't think this is the case the most time. If I need not a function, but a functionality, there's a chance there is an ets table behind or a process, some configuration file setup - then the whole "import a single function" doesn't help, but just adds complications that even the last helper function has to have a globally unique name... From erlang@REDACTED Tue May 24 15:16:24 2011 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 24 May 2011 15:16:24 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: <116CA749-0850-4A35-B580-AC71FB85C569@erlang-solutions.com> References: <116CA749-0850-4A35-B580-AC71FB85C569@erlang-solutions.com> Message-ID: 2011/5/24 Fr?d?ric Trottier-H?bert > The problem of Erlang with regards to namespaces and modules goes further > than just module names. In Erlang, the following units can be > sharing/clashing namespaces: the process registry, ETS tables, module names, > application names, shared records, etc. They're currently entirely disjoint > and only held together by convention. > Absolutely - and inconsistently We can say Pid = spawn(fun() -> ... end) Pid ! M register(name, Pid), name ! Pid But not Mod = load([ .... lists of funs ...]) Mod:reverse(...) register(lists, Mod) lists:reverse(..) same comment for ets tables etc. However, any change to one of the solutions needs to somehow be reflected > into the others, even if it's still by convention. > > IMO the basic hierarchy of Erlang seems to begin with the OTP release. The > name of an OTP application will decide the prefixes used in module names, > process names, table names, shared record names, etc. There is nothing to > check that application names are unique except the programmer looking out > for that, while xref and the compiler can help a bit with the rest. > > I think we can generalise OTP to have this given kind of organisation: > release -> OTP applications -> [Modules, Tables, Shared Records, > Processes] > > An application itself wouldn't have to worry about namespaces (if we forget > included applications). The namespace problem comes at the release stage or > if we're developing entirely outside of OTP, still using applications or > their equivalent. > > To me, this makes it feel like namespace management/giving aliases and > replacement of values should be managed from the release point of view, but > I can't offer any suggestions as to how this could take place without > relying on file renaming and strict use of ?NAMESPACE-like macros throughout > the code. Nothing easily backwards compatible, and nothing to help people > who are not using releases though. > > This in no way would solve Joe's problem with being undecided as to where > functions should go, but I think getting rid of modules altogether in Erlang > wouldn't be doable because of the other dependencies. In places like > Javascript (client-side) or schemes without good module functionality, you > pretty much just include the files and people then tend to wrap everything > in functions or objects to provide an ad-hoc equivalent to namespaces or > modules. I can see this behaviour emerging if Erlang were to go that way. > > I agree - it's not just "getting rid of modules" there's a whole load of other stuff. > -- > Fred H?bert > http://www.erlang-solutions.com > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amphibian.ltd@REDACTED Tue May 24 15:33:35 2011 From: amphibian.ltd@REDACTED (Tim Carpenter) Date: Tue, 24 May 2011 14:33:35 +0100 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: <116CA749-0850-4A35-B580-AC71FB85C569@erlang-solutions.com> Message-ID: (am sending again as this did not seem to get through) Hi all, I am sticking to the request to not comment on other solutions but present my own thoughts... 1. Some units of code only make sense as a collection. who would use part of gen_server in isolation? Well, you could,but to have it separate exposes it to modification that could distort the focused purpose of the unit. 2. some functions have intentionally hidden aspects, private calls etc and these again are best left hidden or considered as a logical whole otherwise side effects or bloat may occur. 3. I see no reason why we cannot logically group functions into modules but not have the code in there...i.e. the module contains references to functions that make it up. this allows logical handling of groups of functions for code management and can allow one function to appear in multiple modules without code duplication. it also allows one to add/delete/replace a function in a module knowing that the source code for the other functions have not been touched! 4. naming conventions should be given great thought for simplicity and intuitiveness. functions could be in n sets, so a strict hierarchy may not suit. 5. if functions are named as being in modules, the need to provide abstraction to the full name may be advantageous, so modulename.sort/3 can be used and the module definition translates this to a unique longhand which can change over time. The programmer should also be able to use the longhand at will using the module as a convenient bulk import/compile vehicle that will break at compile time (one would hope). Some form of 'expects...' notation could allow a form of protection against inadvertent swapping of functions in shared modules altering behaviour. 6. we may want 3 elements to naming of functions: shorthand, longhand, and version, so one can use the latest version of a longhand named function, lock to a specific version of a longhand named function or use the shorthand latest version or other such combinations. 7. n- tier modules - modules of modules? possibly. Tim Tim Carpenter Amphibian Ltd London ENGLAND +44(0)7900 888826 amphibian.ltd@REDACTED From watson.timothy@REDACTED Tue May 24 15:36:36 2011 From: watson.timothy@REDACTED (Tim Watson) Date: Tue, 24 May 2011 14:36:36 +0100 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: > Yes - how this would work I don't know - my Haskell friends say that > searching for > function by type signatures is good. I've only used OCaml commercially, but what little Haskell I've played with this is a very useful feature (hoogle and hackage combined with cabal) for finding and using stuff. > > What do I do today when I suspect that somebody has written some code ? > > > ??? 1) will it take me < ten minutes to write the code? > ??????? yes - write it > ??? 2) google or ask a friend > ??? 3) this gets me to git or sowhere > ??? 4) search > ??? 5) cut-and-paste > > Not a good method - and this is *best practise* Not quite. At point (3) you probably get to github, bitbucket or some such. At that point, you *may* be able to reuse the library and/or application code in your project, in which case you install it with epm/sutro/agner or pull it in as a dependency using rebar. Only when the code is hidden away in the module and not reusable do you have to copy-paste - I think it's this (latter) case that you're not happy with and I agree it's poor show. By way of example, I'm working on a node/cluster monitoring tool (primarily a web application with web sockets notifications). I built the library code (for monitoring) by re-using the eper (performance monitoring) library and a couple of other things (zero-conf for network discovery and whatnot). I built the web application on misultin for its websocket support. I also have some common (to the project) library code which uses the esl/parse_trans library from github to support better use of records and things like that. For the database application, I used the esl/setup library from github to separate the mnesia database/schema setup from the general purpose use cases and to generate (run once) setup scripts and the like. None of this is copy and paste re-use. > Actually for development it would be great to say > > ??? -import("http://a.b.c/modname", [foo/2]). > > this would just make an rcp to foo/2 on the remote host and save all the > pain of locally installing > the necessary code on my machine. I think it would be worth distinguishing between two disparate concerns here. 1. Where does the (binary or other representation of AST) code come from 2. Where does the/any (runtime) state reside I don't always want to RPC just to run a library routine, especially if that call is happing frequently in a tight "loop" and the code needs to run fast. Much as I love Erlang's location transparency, one cannot just assume that the network isn't there. Things I think are potentially awesome here are: 1. Importing from a URI 2. Having the binary code in a repository that is searchable, versioned, etc In fact this is hardly an unfamiliar model - consider couchdb and/or riak. When you define a map-reduce function as say javascript, you distribute/upload this function definition to the server for later use. I think my two major concerns (that are by no means unsurmountable) are: 1. wanting to be able to work when I'm not connected to the code server 2. wanting to be able to define the import based on more than just the name Point (2) is telling. In your example, you imported from http://a.b.c/modname - you still haven't gotten rid of the module. I know it was a flippant example and besides the point. Question is, can you define the search in such a way as to determine exactly where the dispatch must go? The Haskell folks say searching by type is immensely useful, and they're right. But they don't compile based on this - they find what they're looking for and then reference it (explicitly) by name. From watson.timothy@REDACTED Tue May 24 15:37:47 2011 From: watson.timothy@REDACTED (Tim Watson) Date: Tue, 24 May 2011 14:37:47 +0100 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: <1306242428.4959.67.camel@seasc1137> References: <1306233558.4959.61.camel@seasc1137> <1306242428.4959.67.camel@seasc1137> Message-ID: On 24 May 2011 14:07, Bengt Kleberg wrote: > Greetings, > > Perhaps it is possible to do parse_transform when loading, but I have > only heard about this at compile time. I meant a way to load modules, > not compile them. > You could hack something together to do it at runtime if you're importing/loading from an AST rather than a blob. I take your point though - I did misunderstand slightly. From max.lapshin@REDACTED Tue May 24 15:38:19 2011 From: max.lapshin@REDACTED (Max Lapshin) Date: Tue, 24 May 2011 17:38:19 +0400 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: I don't understand what are you speaking about. How do you imagine this magic function namespace in terms of plain files? From watson.timothy@REDACTED Tue May 24 15:44:10 2011 From: watson.timothy@REDACTED (Tim Watson) Date: Tue, 24 May 2011 14:44:10 +0100 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: On 24 May 2011 14:38, Max Lapshin wrote: > I don't understand what are you speaking about. > > How do you imagine this magic function namespace in terms of plain files? > You forget about files. You're code editor (IDE) is now a browser based application. You search for things using a sidebar that ultimately constructs a query to the code server to look for things based on name/version/type-signature/author/safety/etc which becomes a URL. You import things based on URLs. Your code is compiled and hosted on the server. The local file system doesn't have to come into it per se. This last point is partly one of my concerns though. I don't always have an internet connection and something that doesn't work without one is potentially going to cause me problems. Perhaps if it was easy for me to copy the entire repository and run it locally, synchronising when I'm reconnected - that would do nicely. Then the service would be providing something akin to source version control as well. My head now hurts. :) From erlang@REDACTED Tue May 24 16:07:01 2011 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 24 May 2011 16:07:01 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: On Tue, May 24, 2011 at 3:38 PM, Max Lapshin wrote: > I don't understand what are you speaking about. > > How do you imagine this magic function namespace in terms of plain files? > There are no plain files. The functions that you edit and manipulate are stored in a database. When you need to call a library function you query the database it helps you find the function you need from the data in the database - you never know the real name of the function or anything about the namespace it's in. The problem with plain files is that they become unmanageable when there are lots of them. A few years ago I had problem with storage - disks weren't big enough - now I have TBs of raid storage and the next problem arises - how to find stuff. Finding my own code is difficult - it's just a matter of searching 43 K erlang modules on my local disk - finding other peoples code is worse - Google and "ask a friend" is the best solution I know of. As systems get very large the notion of files and modules seems to break down, to be replaced by "search-able stuff in a database" - I'm suggesting that the smallest unit that should be searchable/reusable/discoverable should be the function. And that to make it searchable we need to add a lot of meta data to the functions. -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Tue May 24 16:10:27 2011 From: max.lapshin@REDACTED (Max Lapshin) Date: Tue, 24 May 2011 18:10:27 +0400 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: I can't imagine myself working with system, that uses non-plain files for storing source code. Nobody will fix for me Textmate, git or ack to work with this database. Modules give your clear structure of functions. Without them you will end with mpegts_encode, mpegts_decode, and will break your head when there will be 3 or 4 underscores in name. From atri@REDACTED Tue May 24 16:14:25 2011 From: atri@REDACTED (Barry Skidmore) Date: Tue, 24 May 2011 09:14:25 -0500 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: This conversation is reminiscent of the teapot/teacup architecture from TCL 8.4 http://wiki.tcl.tk/7579 The description of that architecture may be on target? On May 24, 2011, at 9:10 AM, Max Lapshin wrote: > I can't imagine myself working with system, that uses non-plain files > for storing source code. > Nobody will fix for me Textmate, git or ack to work with this database. > > Modules give your clear structure of functions. Without them you will > end with mpegts_encode, mpegts_decode, > and will break your head when there will be 3 or 4 underscores in name. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions Thanks, Barry From erlang@REDACTED Tue May 24 16:15:34 2011 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 24 May 2011 16:15:34 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: <116CA749-0850-4A35-B580-AC71FB85C569@erlang-solutions.com> Message-ID: 2011/5/24 Tim Carpenter > (am sending again as this did not seem to get through) > > > Hi all, > > I am sticking to the request to not comment on other solutions but present > my own thoughts... > > 1. Some units of code only make sense as a collection. who would use part > of gen_server in isolation? Well, you could,but to have it separate exposes > it to modification that could distort the focused purpose of the unit. > > 2. some functions have intentionally hidden aspects, private calls etc and > these again are best left hidden or considered as a logical whole otherwise > side effects or bloat may occur. > > 3. I see no reason why we cannot logically group functions into modules but > not have the code in there...i.e. the module contains references to > functions that make it up. this allows logical handling of groups of > functions for code management and can allow one function to appear in > multiple modules without code duplication. it also allows one to > add/delete/replace a function in a module knowing that the source code for > the other functions have not been touched! > > I checked some numbers. The OTP release has 1793 modules and in these there are 56317 functions with different names. 11887 functions are defined in only one module, ie the for 11887 functions the name alone uniquely identifies the module. The distribution of functions over modules has a long tail with strange spikes, ie most function names are in very small number of modules. But some function names like handle_call etc and in a very large number of modules. Searching for a function using the function name as a key would only lead to a small number of candidate module if we exclude names like handle_call. it would be interesting to do this with type signatures ... > > 4. naming conventions should be given great thought for simplicity and > intuitiveness. functions could be in n sets, so a strict hierarchy may not > suit. > > 5. if functions are named as being in modules, the need to provide > abstraction to the full name may be advantageous, so modulename.sort/3 can > be used and the module definition translates this to a unique longhand which > can change over time. The programmer should also be able to use the longhand > at will using the module as a convenient bulk import/compile vehicle that > will break at compile time (one would hope). Some form of 'expects...' > notation could allow a form of protection against inadvertent swapping of > functions in shared modules altering behaviour. > > 6. we may want 3 elements to naming of functions: shorthand, longhand, and > version, so one can use the latest version of a longhand named function, > lock to a specific version of a longhand named function or use the shorthand > latest version or other such combinations. > I've been thinking about this for a while - sometimes we need a very precise name (including an MD/SHA checksum) othertimes a sloppy name - it depends upon the context. > > 7. n- tier modules - modules of modules? possibly. > I think these are "views" not names - we have functions and then different ways to view them, in collections of different kinds > > Tim > Tim Carpenter > Amphibian Ltd > London > ENGLAND > +44(0)7900 888826 > amphibian.ltd@REDACTED > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Tue May 24 16:22:25 2011 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 24 May 2011 16:22:25 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: On Tue, May 24, 2011 at 4:10 PM, Max Lapshin wrote: > I can't imagine myself working with system, that uses non-plain files > for storing source code. > Nobody will fix for me Textmate, git or ack to work with this database. > Why not? - a plain text file is an abstraction - in reality its a collection of magnetised zones on a disk, or electron spin states or something, this gets turned into a collection of bits, the bits are rendered in a editor. Plain text doesn't exist - it's just an abstraction. The underlying representation of the data you see in a browser may come from a file or as the result of a datebase query, you will never know which it was. > > Modules give your clear structure of functions. Without them you will > end with mpegts_encode, mpegts_decode, > and will break your head when there will be 3 or 4 underscores in name. > or should the name be encode_mpegts and decode_mpegts the problem with structured names is choosing the name - not the fact there is structure in the name. Imagine the www was just one big structured name and there were no search engines how would you ever find anything? /Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From cyplo@REDACTED Tue May 24 16:30:23 2011 From: cyplo@REDACTED (=?UTF-8?Q?Cyryl_P=C5=82otnicki=2DChudyk?=) Date: Tue, 24 May 2011 16:30:23 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: On Tue, May 24, 2011 at 4:22 PM, Joe Armstrong wrote: > > Why not? - a plain text file is an abstraction - in reality its a collection > of magnetised zones > on a disk, or electron spin states or something, this gets turned into a > collection of > bits, the bits are rendered in a editor. Plain text doesn't exist - it's > just an abstraction. > How about storing the code in the old school plain text files but with additional, also plain text, index/metadata files ? That would satisfy both the searchability and legacy compatibility -- cyryl From nox@REDACTED Tue May 24 16:31:43 2011 From: nox@REDACTED (Anthony Ramine) Date: Tue, 24 May 2011 16:31:43 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: <9ED39284-56EE-4FA3-9985-C806339BEAB4@dev-extend.eu> Le 24 mai 2011 ? 14:45, Joe Armstrong a ?crit : > On Tue, May 24, 2011 at 1:56 PM, Max Lapshin wrote: > Very strange topic for me. > > I'd like to know if there will be hierarchial modules in Erlang, > because tree of packages is a rather good idea: > > No it's not - this has been the subject of long and heated discussion and is > why packages are NOT in Erlang - many people - myself included - dislike > the idea of hierarchical namespaces. The *dot* in the name has no semantics > it's just a separator. The name could equally well be encoders.mpg.erlyvideo > or mpg.applications.erlvideo.encoder - there is no logical way to organise the > package name and it does not scale - packages are NOT in Erlang? Then the related code should be removed because erl.lang.number:plus(1, 1) definitely works. Also, I think the Haskell guys would disagree about packages not scaling. -- Anthony Ramine Dev:Extend http://dev-extend.eu From jack@REDACTED Tue May 24 16:32:37 2011 From: jack@REDACTED (Jack Moffitt) Date: Tue, 24 May 2011 08:32:37 -0600 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: > I can't imagine myself working with system, that uses non-plain files > for storing source code. > Nobody will fix for me Textmate, git or ack to work with this database. I remember when Zope worked like this. I hated it, and to my knowledge, none of the editors picked up support for it despite it being pretty popular at the time. I believe they later changed to uisng the normal filesystem, but it's been a long time since I paid any attention to that project. jack. From rtrlists@REDACTED Tue May 24 16:41:28 2011 From: rtrlists@REDACTED (Robert Raschke) Date: Tue, 24 May 2011 15:41:28 +0100 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: On Tue, May 24, 2011 at 3:07 PM, Joe Armstrong wrote: > > > On Tue, May 24, 2011 at 3:38 PM, Max Lapshin wrote: > >> I don't understand what are you speaking about. >> >> How do you imagine this magic function namespace in terms of plain files? >> > > There are no plain files. The functions that you edit and manipulate are > stored in a database. > > When you need to call a library function you query the database it helps > you find the function > you need from the data in the database - you never know the real name of > the function or anything about > the namespace it's in. > > The problem with plain files is that they become unmanageable when there > are lots of them. > > A few years ago I had problem with storage - disks weren't big enough - now > I have TBs of > raid storage and the next problem arises - how to find stuff. Finding my > own code is difficult - > it's just a matter of searching 43 K erlang modules on my local disk - > finding other peoples > code is worse - Google and "ask a friend" is the best solution I know of. > > As systems get very large the notion of files and modules seems to break > down, to be > replaced by "search-able stuff in a database" - I'm suggesting that the > smallest unit that > should be searchable/reusable/discoverable should be the function. And that > to make it > searchable we need to add a lot of meta data to the functions. > > For some reason this reminds me of a cross between Smalltalk and Eiffel. Robby -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Tue May 24 16:43:54 2011 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Tue, 24 May 2011 16:43:54 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: <9ED39284-56EE-4FA3-9985-C806339BEAB4@dev-extend.eu> References: <9ED39284-56EE-4FA3-9985-C806339BEAB4@dev-extend.eu> Message-ID: On Tue, May 24, 2011 at 16:31, Anthony Ramine wrote: > > packages are NOT in Erlang? Then the related code should be removed because > erl.lang.number:plus(1, 1) definitely works. > The problem is that a package hierarchy enforces a tree-like structure. And we may not want the tree. You might want the same module to reside in multiple packages in the hierarchy at the same time. We are past 2005 now and we know what a tag cloud is. About time we began thinking of how that would fit into a programming lang. :-) The only real advantage of a package tree is that you can: * Shove some packages underneath a common notifier. This limits the packages currently in scope. * Shortcut reference to package if they nest. I think both would be better served by a system different from hierarchy. -- J. From fred.hebert@REDACTED Tue May 24 16:44:42 2011 From: fred.hebert@REDACTED (=?iso-8859-1?Q?Fr=E9d=E9ric_Trottier-H=E9bert?=) Date: Tue, 24 May 2011 10:44:42 -0400 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: <72398817-25A7-4AA1-B502-A5EB9D3FBC54@erlang-solutions.com> One issue is that while plain files are abstractions, they are a very common one, compatible with most systems you will see in use, and on which many tools have been developed, including source control, IDEs, e-mail attachments, documentation and conversation. I do not see the idea of a database as inherently bad -- it could be a good supplement to the developer, much like module_info is for modules. Using a DB for everything (with unique IDs) could solve the problem of nested dependencies, where library A needs library B 1.1.2 while library C needs B 1.2.0 and both can not be loaded at once. But the social problems it creates -- how to communicate about functions, how to regroup collections of them in an exportable way, how to version them, how to patch them, how to reload them, etc. are not worth the change, I believe. The code server or the VM could likely use any representation it likes for these, but the developers are used to one way of doing things, including existing projects. This isn't only a question of compatibility with older code, but also with developers. I think I could welcome a good function/module database in Erlang, something that could be as responsive as erldocs.com, but could be integrated straight to the shell or something that makes the developer's life easier and maintenance of code easier. I doubt switching to database would simplify the issues at hand. To me it sounds like we'd solve a problem, but create a bunch more that were already considered solved. It might be that everything was built on faulty assumptions, but then this sounds like the whole thing would need to be re-worked from scratch, not just the current module system. You might want to look at the way PLaneT is doing things for racket, too (http://docs.racket-lang.org/planet/Using_PLaneT.html?q=planet) You can basically import Racket/Scheme module from a server, either at run time or at build time. -- Fred H?bert http://www.erlang-solutions.com On 2011-05-24, at 10:22 AM, Joe Armstrong wrote: > > > On Tue, May 24, 2011 at 4:10 PM, Max Lapshin wrote: > I can't imagine myself working with system, that uses non-plain files > for storing source code. > Nobody will fix for me Textmate, git or ack to work with this database. > > Why not? - a plain text file is an abstraction - in reality its a collection of magnetised zones > on a disk, or electron spin states or something, this gets turned into a collection of > bits, the bits are rendered in a editor. Plain text doesn't exist - it's just an abstraction. > > The underlying representation of the data you see in a browser may come from a file > or as the result of a datebase query, you will never know which it was. > > > Modules give your clear structure of functions. Without them you will > end with mpegts_encode, mpegts_decode, > and will break your head when there will be 3 or 4 underscores in name. > > or should the name be encode_mpegts and decode_mpegts the problem with structured names > is choosing the name - not the fact there is structure in the name. > > Imagine the www was just one big structured name and there were no search engines > how would you ever find anything? > > /Joe > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From jack@REDACTED Tue May 24 16:47:16 2011 From: jack@REDACTED (Jack Moffitt) Date: Tue, 24 May 2011 08:47:16 -0600 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: <9ED39284-56EE-4FA3-9985-C806339BEAB4@dev-extend.eu> Message-ID: > The problem is that a package hierarchy enforces a tree-like > structure. And we may not want the tree. You might want the same > module to reside in multiple packages in the hierarchy at the same > time. We are past 2005 now and we know what a tag cloud is. About time > we began thinking of how that would fit into a programming lang. :-) Wouldn't you just use a DAG? Even with plain tags, you'd need to do something about cycles. jack. From jesper.louis.andersen@REDACTED Tue May 24 16:48:12 2011 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Tue, 24 May 2011 16:48:12 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: On Tue, May 24, 2011 at 16:10, Max Lapshin wrote: > I can't imagine myself working with system, that uses non-plain files > for storing source code. On a side-related note: I think it is a grand mistake to enforce the "one file per module" convention. Modules should be created by virtue of the wish of a programmer. Not by a single file. The current convention begs for trouble as soon as you want to load a library of several modules off of the network via an http://-reference for instance. If you could have several modules in a single file, then reference would simply be to a single URI. Worse it is to enforce that the package hierarchy is a directory structure as in Java. It is not very compatible with the greatest programming IDE of all time: UNIX. -- J. From vladdu55@REDACTED Tue May 24 16:50:09 2011 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Tue, 24 May 2011 16:50:09 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: <72398817-25A7-4AA1-B502-A5EB9D3FBC54@erlang-solutions.com> References: <72398817-25A7-4AA1-B502-A5EB9D3FBC54@erlang-solutions.com> Message-ID: 2011/5/24 Fr?d?ric Trottier-H?bert > One issue is that while plain files are abstractions, they are a very > common one, compatible with most systems you will see in use, and on which > many tools have been developed, including source control, IDEs, e-mail > attachments, documentation and conversation. > > I do not see the idea of a database as inherently bad -- it could be a good > supplement to the developer, much like module_info is for modules. Using a > DB for everything (with unique IDs) could solve the problem of nested > dependencies, where library A needs library B 1.1.2 while library C needs B > 1.2.0 and both can not be loaded at once. > > But the social problems it creates -- how to communicate about functions, > how to regroup collections of them in an exportable way, how to version > them, how to patch them, how to reload them, etc. are not worth the change, > I believe. > One can always create a virtual filesystem on top of the database. One can also implement a virtual database on top of the filesystem. regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Tue May 24 16:50:34 2011 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 24 May 2011 16:50:34 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: <9ED39284-56EE-4FA3-9985-C806339BEAB4@dev-extend.eu> References: <9ED39284-56EE-4FA3-9985-C806339BEAB4@dev-extend.eu> Message-ID: On Tue, May 24, 2011 at 4:31 PM, Anthony Ramine wrote: > > Le 24 mai 2011 ? 14:45, Joe Armstrong a ?crit : > > > On Tue, May 24, 2011 at 1:56 PM, Max Lapshin > wrote: > > Very strange topic for me. > > > > I'd like to know if there will be hierarchial modules in Erlang, > > because tree of packages is a rather good idea: > > > > No it's not - this has been the subject of long and heated discussion and > is > > why packages are NOT in Erlang - many people - myself included - dislike > > the idea of hierarchical namespaces. The *dot* in the name has no > semantics > > it's just a separator. The name could equally well be > encoders.mpg.erlyvideo > > or mpg.applications.erlvideo.encoder - there is no logical way to > organise the > > package name and it does not scale - > > packages are NOT in Erlang? Then the related code should be removed because > erl.lang.number:plus(1, 1) definitely works. > Yes - this is an experiment unapproved feature which could be removed at any time. This is how we do things - we add experimental and undocumented features and reserve the right to remove them at any time in the future. Packages are not officially documented and thus not officially supported. > > Also, I think the Haskell guys would disagree about packages not scaling. > > -- > Anthony Ramine > Dev:Extend > http://dev-extend.eu > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu55@REDACTED Tue May 24 16:55:30 2011 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Tue, 24 May 2011 16:55:30 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: <116CA749-0850-4A35-B580-AC71FB85C569@erlang-solutions.com> Message-ID: On Tue, May 24, 2011 at 16:15, Joe Armstrong wrote: > The OTP release has 1793 modules and in these there are 56317 functions > with different names. > 11887 functions are defined in only one module, ie the for 11887 functions > the name alone uniquely > identifies the module. The distribution of functions over modules has a > long tail with strange spikes, > ie most function names are in very small number of modules. But some > function names like handle_call > etc and in a very large number of modules. > > Searching for a function using the function name as a key would only lead > to a small number of candidate module if we exclude names like handle_call. > > it would be interesting to do this with type signatures ... > If I understand correctly, it would then be necessary to have a database over all types, too. And a way to detect when types are identical, and a way to search types based on some meta-data associated with them... It might work, but it's a *lot* of work (pun intended) and I'm not sure how it would mix with existing codebases. More thinking required. regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From nox@REDACTED Tue May 24 16:58:57 2011 From: nox@REDACTED (Anthony Ramine) Date: Tue, 24 May 2011 16:58:57 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: <9ED39284-56EE-4FA3-9985-C806339BEAB4@dev-extend.eu> Message-ID: Le 24 mai 2011 ? 16:50, Joe Armstrong a ?crit : > > > On Tue, May 24, 2011 at 4:31 PM, Anthony Ramine wrote: > > Le 24 mai 2011 ? 14:45, Joe Armstrong a ?crit : > > > On Tue, May 24, 2011 at 1:56 PM, Max Lapshin wrote: > > Very strange topic for me. > > > > I'd like to know if there will be hierarchial modules in Erlang, > > because tree of packages is a rather good idea: > > > > No it's not - this has been the subject of long and heated discussion and is > > why packages are NOT in Erlang - many people - myself included - dislike > > the idea of hierarchical namespaces. The *dot* in the name has no semantics > > it's just a separator. The name could equally well be encoders.mpg.erlyvideo > > or mpg.applications.erlvideo.encoder - there is no logical way to organise the > > package name and it does not scale - > > packages are NOT in Erlang? Then the related code should be removed because > erl.lang.number:plus(1, 1) definitely works. > > Yes - this is an experiment unapproved feature which could be removed at any time. > > This is how we do things - we add experimental and undocumented features > and reserve the right to remove them at any time in the future. Packages are not > officially documented and thus not officially supported. Well then, forgive me for this little offtopic but you seem to know what is unapproved and what is unfinished. Are structs - not your proper structs but the commented-out production found in erl_parse.yrl struct -> atom tuple - an unapproved feature or an unfinished feature? Regards, -- Anthony Ramine Dev:Extend http://dev-extend.eu From erlang@REDACTED Tue May 24 17:05:34 2011 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 24 May 2011 17:05:34 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: <9ED39284-56EE-4FA3-9985-C806339BEAB4@dev-extend.eu> Message-ID: Not guilty - I've no idea actually - probably an unfinished experiment ... /Joe On Tue, May 24, 2011 at 4:58 PM, Anthony Ramine wrote: > Le 24 mai 2011 ? 16:50, Joe Armstrong a ?crit : > > > > > > > On Tue, May 24, 2011 at 4:31 PM, Anthony Ramine > wrote: > > > > Le 24 mai 2011 ? 14:45, Joe Armstrong a ?crit : > > > > > On Tue, May 24, 2011 at 1:56 PM, Max Lapshin > wrote: > > > Very strange topic for me. > > > > > > I'd like to know if there will be hierarchial modules in Erlang, > > > because tree of packages is a rather good idea: > > > > > > No it's not - this has been the subject of long and heated discussion > and is > > > why packages are NOT in Erlang - many people - myself included - > dislike > > > the idea of hierarchical namespaces. The *dot* in the name has no > semantics > > > it's just a separator. The name could equally well be > encoders.mpg.erlyvideo > > > or mpg.applications.erlvideo.encoder - there is no logical way to > organise the > > > package name and it does not scale - > > > > packages are NOT in Erlang? Then the related code should be removed > because > > erl.lang.number:plus(1, 1) definitely works. > > > > Yes - this is an experiment unapproved feature which could be removed at > any time. > > > > This is how we do things - we add experimental and undocumented features > > and reserve the right to remove them at any time in the future. Packages > are not > > officially documented and thus not officially supported. > > Well then, forgive me for this little offtopic but you seem to know what is > unapproved > and what is unfinished. Are structs - not your proper structs but the > commented-out > production found in erl_parse.yrl struct -> atom tuple - an unapproved > feature or an > unfinished feature? > > Regards, > > > -- > Anthony Ramine > Dev:Extend > http://dev-extend.eu > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ixmatus@REDACTED Tue May 24 17:31:05 2011 From: ixmatus@REDACTED (Parnell Springmeyer) Date: Tue, 24 May 2011 08:31:05 -0700 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: (Tim Watson's message of "Tue, 24 May 2011 12:19:27 +0100") References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I actually came here to suggest Python's implementation of packages and modules - it confuses a lot of people at first, but it's actually quite powerful and I wish Erlang would do something more like it. Packages are a group of modules (modules are files in python, just like erlang) that can be sub-divided into sub-packages within that package using the filesystem, __init__.py files and naming. My apologies if this is already understood. The language I would point at as an example of a "mess" would be something like PHP. To comment on your suggestion: I much like the idea being able to inherit modules, to do it the "Erlang way", I think that may be one of the better and least painful-to-change routes. - -- Parnell "ixmatus" Springmeyer (http://ixmat.us) -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJN2886AAoJEPvtlbpI1POLZn0IAL2f62A5CrSroCi5XVwVACRX Ecbq0Dzesqls61wK9gtX2lpEA16DEuxubz2m5FrGoKB18h4olrUi7fF7JCHcyEl6 +tc/rLwsGtvkE3bHrSRjbB7KTOEP1Dfa76i9xNvyPJXMZ8qdA3TBwKwiIhAx72a/ V1XkzEy4Z30UL7gWpysLkMc48p1LpoPnaTA20A5AXgcFd3SkzcuARRheWoEnuT1u L6N3FfR3glELYaNjQYiBxbOOuR8vS4kxVxk78NLgOGY87t4JGdNvmcXt/64lhxkN 3zNJnclr8zA+JLyernUPNpGDWV9fAuzpzkDExI0+57v3MN4TpnN1GEblj8l65Ao= =XGb2 -----END PGP SIGNATURE----- From moxford@REDACTED Tue May 24 17:34:03 2011 From: moxford@REDACTED (Mike Oxford) Date: Tue, 24 May 2011 08:34:03 -0700 Subject: [erlang-questions] System timers, now/0, and instrumentation In-Reply-To: References: <673380092.213661306227737701.JavaMail.root@zimbra> Message-ID: I'm still a newbie, but you could write a port/BIF in C which calls into the Windows high-resolution timers. You'll lose a tiny bit but I'd think you'll get better than 1ms resolutions. -mox On Tue, May 24, 2011 at 2:32 AM, Amy Lear wrote: > On Tue, May 24, 2011 at 2:02 AM, Magnus Henoch < > magnus.henoch@REDACTED> wrote: > >> ----- "Amy Lear" wrote: >> >> > The issue here as I understand it is that the system clock itself >> > can't report things in the microsecond range (msdn states the >> > granularity is between 10ms and 15ms: >> > >> http://msdn.microsoft.com/en-us/library/system.datetimeoffset.utcnow.aspx >> > ), but the real values are being mangled to provide those guaranteed >> > unique values. Given that now/0 is the obvious means of doing >> > measurement for an erlang user -- and in fact the instrumentation >> > tools that ship with erlang also appear to rely on it -- this results >> > in puzzling and undesired behavior. >> >> Have you tried os:timestamp/0? It's like now/0 but without the >> uniqueness guarantee. I'm not sure what granularity it has on >> Windows, though. >> >> Hope this helps, >> > > Unfortunately, it appears that the granularity of os:timestamp/0 is no > finer than 1 ms, and the minimum resolution appears to be machine-dependant. > Msdn research also suggests that the 1ms resolution timer is slower to > access than the normal system clock, which could matter in some > circumstances. Conversely, dropping the uniqueness facet and being higher > resolution than now/0 does have some potential usefulness, but the erlang > documentation indicates that the provided profiling tools rely on now/0. > > My question about instrumentation stands: is there currently a way to do > high resolution profiling in Erlang on Windows? Is the requisite work of > setting up sub-ms resolution timers simply not done/too much work to > attempt? > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jack@REDACTED Tue May 24 17:42:32 2011 From: jack@REDACTED (Jack Moffitt) Date: Tue, 24 May 2011 09:42:32 -0600 Subject: [erlang-questions] System timers, now/0, and instrumentation In-Reply-To: References: <673380092.213661306227737701.JavaMail.root@zimbra> Message-ID: > I'm still a newbie, but you could write a port/BIF in C which calls into the > Windows high-resolution timers. ?You'll lose a tiny bit but I'd think you'll > get better than 1ms resolutions. Better yet, replace the implementation of now() with the high resolution timers on Windows. jack. From ixmatus@REDACTED Tue May 24 17:56:10 2011 From: ixmatus@REDACTED (Parnell Springmeyer) Date: Tue, 24 May 2011 08:56:10 -0700 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: <9ED39284-56EE-4FA3-9985-C806339BEAB4@dev-extend.eu> (Anthony Ramine's message of "Tue, 24 May 2011 16:31:43 +0200") References: <9ED39284-56EE-4FA3-9985-C806339BEAB4@dev-extend.eu> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I really like the idea of packages - I'm not quite sure why everyone is against them... Even Racket has extended the syntax of Scheme to the point where they support packages and modules now; it's a very natural abstraction for the human mind IMHO. I would, personally, stop using (or fork) the language if I were forced to program connected to a DB. If it were a local ets-like DB that started when the Erlang VM started, cool. But not an over-the-internet type of thing, this is a particularly bad idea too because some applications really do need to be network efficient; if my language adds overhead to my network because it needs to request the definition of a function over the internet, that is A Bad Thing. I don't like the idea loading everything when the VM starts. I much prefer (and wish Erlang did it this way) the concept of calling an import statement. I like being able to see what packages, modules, and functions another module is referencing. Additionally this solves the issue of pre-loading the entire namespace when the VM starts; you only import when you /need/ it. I am intrigued, however, by the idea of type signatures and finding functions based on their metadata - cool idea. In practice though, I would really hate maintaining the metadata for every function I've wrote! I much rather group common functions into a module and then annotate the module with metadata. Anthony Ramine writes: > Le 24 mai 2011 ? 14:45, Joe Armstrong a ?crit : > >> On Tue, May 24, 2011 at 1:56 PM, Max Lapshin wrote: >> Very strange topic for me. >> >> I'd like to know if there will be hierarchial modules in Erlang, >> because tree of packages is a rather good idea: >> >> No it's not - this has been the subject of long and heated discussion and is >> why packages are NOT in Erlang - many people - myself included - dislike >> the idea of hierarchical namespaces. The *dot* in the name has no semantics >> it's just a separator. The name could equally well be encoders.mpg.erlyvideo >> or mpg.applications.erlvideo.encoder - there is no logical way to organise the >> package name and it does not scale - > > packages are NOT in Erlang? Then the related code should be removed because > erl.lang.number:plus(1, 1) definitely works. > > Also, I think the Haskell guys would disagree about packages not scaling. > > -- > Anthony Ramine > Dev:Extend > http://dev-extend.eu > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > - -- Parnell "ixmatus" Springmeyer (http://ixmat.us) -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJN29UaAAoJEPvtlbpI1POLpSAH/ijpOgfq1F+AF140/aXZke6C EXrWaiFBOgna0lkKu4lmwusOebLbyoiPs9D9vstlVff7npZ4Zdw32fp9LRuBjwfY rgGesMBoUGNMtpzXuuduCH7CkZNCIrBXj8uvKOBlDxt5csOz8FCpxvKDOXZg/z0I bFMP0HTYj1pzC2ixk2RmlUdKdbMLCCriIU+n0R5f4lIEck1FcoDm233ZHv1Sv9QC 9PlQ4kF91H/CavPAdD/JX4sDp6NRTCjV/VWCUzDTOyK/11/fl4R7nAB61TXzkVmz tv3y5z5RCkfjlatgvGSQ3d9vRbSn5fQneguxMX54JHI0WTEcWZ3xCQZZ8QKPuhY= =Faf+ -----END PGP SIGNATURE----- From watson.timothy@REDACTED Tue May 24 17:57:01 2011 From: watson.timothy@REDACTED (Tim Watson) Date: Tue, 24 May 2011 16:57:01 +0100 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: > For some reason this reminds me of a cross between Smalltalk and Eiffel. Yes, smalltalk had/has everything bootstrapped into the one environment, including the editor, stdlib, object system, etc. From watson.timothy@REDACTED Tue May 24 18:03:51 2011 From: watson.timothy@REDACTED (Tim Watson) Date: Tue, 24 May 2011 17:03:51 +0100 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: <9ED39284-56EE-4FA3-9985-C806339BEAB4@dev-extend.eu> Message-ID: On 24 May 2011 16:56, Parnell Springmeyer wrote: > I really like the idea of packages - I'm not quite sure why everyone is > against them... Even Racket has extended the syntax of Scheme to the > point where they support packages and modules now; it's a very natural > abstraction for the human mind IMHO. I've tried using them, but the lack of support makes it difficult. The bugs in the cover tool you can get around by doing -import(ets) in every module that needs to be cover compiled and as a work-around that fixes it. But reltool doesn't work so beam files in package sub-directories beneath ebin do not get copied into the release. There are probably other bugs too. > I don't like the idea loading everything when the VM starts. I much > prefer (and wish Erlang did it this way) the concept of calling an > import statement. I like being able to see what packages, modules, and > functions another module is referencing. You can already (today) choose whether everything loads on startup or on demand (i.e., when you call Mod:Func(Args)) by choosing to run the VM as an embedded system or not. To see what packages, modules and functions your modules are referencing, you can use the xref tool which comes with the standard distribution and is supported by tools like rebar. > I am intrigued, however, by the idea of type signatures and finding > functions based on their metadata - cool idea. Yes, this works particularly well for haskell (e.g., hoogle) and combined with cabal/hackage makes it easy to find what you need based mainly on type signatures. Sadly type signatures are often *all* the documentation you get of a Haskell library/application, which unless you're a type guru can be just as frustrating as write-yourself/cut+paste and often more so than google=>github=>rebar-deps. > > In practice though, I would really hate maintaining the metadata for > every function I've wrote! I much rather group common functions into a > module and then annotate the module with metadata. > If extra metadata were to be attached to functions, this should/would be generated by the compiler anyway. Personally, I think a step in the right direction would be to preserve type signatures at runtime - something that has been discussed elsewhere on this list not that long ago IIRC. From dsc@REDACTED Tue May 24 18:05:01 2011 From: dsc@REDACTED (Dave Challis) Date: Tue, 24 May 2011 17:05:01 +0100 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: <4DDBD72D.50309@ecs.soton.ac.uk> Message-ID: One thing I'd argue is that modules go some way to indicating the intent of functions within (though maybe this can be replaced with good function metadata). Let's say we've got a sets module which happens to implement set data structures as lists. This sets module might define some generally useful list manipulation functions, which others want to use. However, the intent of those functions is to serve the sets module. If the module owner wants to change one of the functions to be faster for certain types of list and slower for others, it would make sense to do so if it improved performance of the sets module as a whole. If that function was in a global namespace of functions, it would need metadata which indicated something like: "Although this is a general list processing function, it is intended to support set data structures, and as such may change internally to best serve this set of functions here." I guess what I'm trying to say is that I can see the need for code duplication when you've got: X, a function intended to do X Y, a function intended to do Y, which happens to be implemented as X Though the code for them might look identical, there's the implied contract that X will always do X, whereas Y could change at any time. Modules (or namespaces in other languages) seem to be a reasonable way of describing this intent/contract (albeit in vague terms, though most modules seem to have an understandable purpose or theme). -- Dave Challis dsc@REDACTED From watson.timothy@REDACTED Tue May 24 18:05:42 2011 From: watson.timothy@REDACTED (Tim Watson) Date: Tue, 24 May 2011 17:05:42 +0100 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: <9ED39284-56EE-4FA3-9985-C806339BEAB4@dev-extend.eu> Message-ID: > > Personally, I think a step in the right direction would be to preserve > type signatures at runtime - something that has been discussed > elsewhere on this list not that long ago IIRC. > Sorry - that wasn't what I meant to say. Rather, I think that it would be good to preserve type specifications in the beam code for a compiled module, which doesn't happen at present. From zabrane3@REDACTED Tue May 24 18:16:03 2011 From: zabrane3@REDACTED (Zabrane Mickael) Date: Tue, 24 May 2011 18:16:03 +0200 Subject: [erlang-questions] esmtp: send PDF as an attachment Message-ID: <22D4C8B4-9E83-4380-A9A9-06D0E871107F@gmail.com> Hi guys, I'd like to use "esmtp" to send emails with attachment: https://github.com/archaelus/esmtp Unfortunately, the doc is a bit sparse. Could someone help on how for email send an email with a PDF (eg. /tmp/foo.pdf) as an attachment? Thanks ! Regards, Zabrane -------------- next part -------------- An HTML attachment was scrubbed... URL: From adiaz@REDACTED Tue May 24 18:52:48 2011 From: adiaz@REDACTED (Amancio =?ISO-8859-1?Q?D=EDaz_Su=E1rez?=) Date: Tue, 24 May 2011 18:52:48 +0200 Subject: [erlang-questions] esmtp: send PDF as an attachment In-Reply-To: <22D4C8B4-9E83-4380-A9A9-06D0E871107F@gmail.com> References: <22D4C8B4-9E83-4380-A9A9-06D0E871107F@gmail.com> Message-ID: <1306255968.27369.156.camel@cag0001w798> Hi Mickael, I got something like this and works fine. MimeContent = #mime_part{data = NewContent, type = inline, encoding = {"7bit","text/html","utf-8"}, name = "txt.html"}, {ok, PngContent0} = file:read_file(?MAIL_PNG_LOGO), PngContent1 = base64:encode(PngContent0), PngContent = erlang:binary_to_list(PngContent1), Atach2 = #mime_part{data = PngContent, type = attachment, encoding= {"base64", "image/png", "iso-8859-1"}, name= FileNameLogo}, Msg0 = #mime_msg{} = esmtp_mime:msg(SmtpTo, SmtpFrom, SmtpSubject), Msg = Msg0#mime_msg{parts = [MimeContent, Atach2]}, esmtp:send(Msg). change the MIME type, use "application/pdf" instead of "image/png". Amancio. El mar, 24-05-2011 a las 18:16 +0200, Zabrane Mickael escribi?: > Hi guys, > > > I'd like to use "esmtp" to send emails with attachment: > https://github.com/archaelus/esmtp > > > Unfortunately, the doc is a bit sparse. > > > Could someone help on how for email send an email with a PDF > (eg. /tmp/foo.pdf) as an attachment? > Thanks ! > > Regards, > Zabrane > > From amindfv@REDACTED Tue May 24 18:54:50 2011 From: amindfv@REDACTED (Tom Murphy) Date: Tue, 24 May 2011 12:54:50 -0400 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: <9ED39284-56EE-4FA3-9985-C806339BEAB4@dev-extend.eu> Message-ID: On 5/24/11, Parnell Springmeyer wrote: > In practice though, I would really hate maintaining the metadata for > every function I've wrote! I much rather group common functions into a > module and then annotate the module with metadata. Ideally, it wouldn't just be just you maintaining the metadata - if the functions were in the centralized DB, others could suggest or make changes, wikipedia-style. Tom From moxford@REDACTED Tue May 24 19:48:40 2011 From: moxford@REDACTED (Mike Oxford) Date: Tue, 24 May 2011 10:48:40 -0700 Subject: [erlang-questions] System timers, now/0, and instrumentation In-Reply-To: References: <673380092.213661306227737701.JavaMail.root@zimbra> Message-ID: Breaks compatibility (backwards and cross platform.) -mox On Tue, May 24, 2011 at 8:42 AM, Jack Moffitt wrote: > > I'm still a newbie, but you could write a port/BIF in C which calls into > the > > Windows high-resolution timers. You'll lose a tiny bit but I'd think > you'll > > get better than 1ms resolutions. > > Better yet, replace the implementation of now() with the high > resolution timers on Windows. > > jack. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zabrane3@REDACTED Tue May 24 20:11:14 2011 From: zabrane3@REDACTED (Zabrane Mickael) Date: Tue, 24 May 2011 20:11:14 +0200 Subject: [erlang-questions] esmtp: send PDF as an attachment In-Reply-To: <1306255968.27369.156.camel@cag0001w798> References: <22D4C8B4-9E83-4380-A9A9-06D0E871107F@gmail.com> <1306255968.27369.156.camel@cag0001w798> Message-ID: <287460A3-6AE1-4881-BE89-3D2D1E20AA7C@gmail.com> Hi Amancio, Worked like a charm. Thanks again ;-) Regards, Zabrane Le 24 mai 2011 ? 18:52, Amancio D?az Su?rez a ?crit : > Hi Mickael, > > I got something like this and works fine. > > > MimeContent = #mime_part{data = NewContent, > type = inline, > encoding = {"7bit","text/html","utf-8"}, > name = "txt.html"}, > > {ok, PngContent0} = file:read_file(?MAIL_PNG_LOGO), > PngContent1 = base64:encode(PngContent0), > PngContent = erlang:binary_to_list(PngContent1), > > Atach2 = #mime_part{data = PngContent, > type = attachment, > encoding= {"base64", "image/png", > "iso-8859-1"}, > name= FileNameLogo}, > > Msg0 = #mime_msg{} = esmtp_mime:msg(SmtpTo, SmtpFrom, SmtpSubject), > Msg = Msg0#mime_msg{parts = [MimeContent, Atach2]}, > esmtp:send(Msg). > > > change the MIME type, use "application/pdf" instead of "image/png". > > Amancio. > > > El mar, 24-05-2011 a las 18:16 +0200, Zabrane Mickael escribi?: >> Hi guys, >> >> >> I'd like to use "esmtp" to send emails with attachment: >> https://github.com/archaelus/esmtp >> >> >> Unfortunately, the doc is a bit sparse. >> >> >> Could someone help on how for email send an email with a PDF >> (eg. /tmp/foo.pdf) as an attachment? >> Thanks ! >> >> Regards, >> Zabrane >> >> > > > From erlang@REDACTED Tue May 24 20:14:29 2011 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 24 May 2011 20:14:29 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: <9ED39284-56EE-4FA3-9985-C806339BEAB4@dev-extend.eu> Message-ID: On Tue, May 24, 2011 at 5:56 PM, Parnell Springmeyer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I really like the idea of packages - I'm not quite sure why everyone is > against them... Even Racket has extended the syntax of Scheme to the > point where they support packages and modules now; it's a very natural > abstraction for the human mind IMHO. > > I would, personally, stop using (or fork) the language if I were forced > to program connected to a DB. Why? Who cares how the data is stored - the requirements on storage would be never-loose-anything fast latency access form any machine I'd imaging a fast local db, that synced with some cloud storage and where you could work on-or off-line with periods of no net access. If your machine were struck by lightening you should be ably to resume on any other machine, possibly loosing a very small ammount of data. I imagine a local copy of couchDB with off-site replicas would be ok for this. > If it were a local ets-like DB that > started when the Erlang VM started, cool. Ets is too fast - we don't need to be ets fast :-) > But not an over-the-internet > type of thing, this is a particularly bad idea too because some > applications really do need to be network efficient; if my language adds > overhead to my network because it needs to request the definition of a > function over the internet, that is A Bad Thing. > It's a trade off - if you always store modified functions in the net the most you can loose is one function. If you don't you might loose a lot of work if your machine suddenly disintegrates. Umm let's think - in a good day I might write 500 lines of code say 500 * 50 bytes in 86400 seconds that's 0.3 bits/second I might look at ten times as much code - but I'd cache that locally. /Joe > > I don't like the idea loading everything when the VM starts. I much > prefer (and wish Erlang did it this way) the concept of calling an > import statement. I like being able to see what packages, modules, and > functions another module is referencing. > > Additionally this solves the issue of pre-loading the entire namespace > when the VM starts; you only import when you /need/ it. > > I am intrigued, however, by the idea of type signatures and finding > functions based on their metadata - cool idea. > > In practice though, I would really hate maintaining the metadata for > every function I've wrote! I much rather group common functions into a > module and then annotate the module with metadata. > > Anthony Ramine writes: > > > Le 24 mai 2011 ? 14:45, Joe Armstrong a ?crit : > > > >> On Tue, May 24, 2011 at 1:56 PM, Max Lapshin > wrote: > >> Very strange topic for me. > >> > >> I'd like to know if there will be hierarchial modules in Erlang, > >> because tree of packages is a rather good idea: > >> > >> No it's not - this has been the subject of long and heated discussion > and is > >> why packages are NOT in Erlang - many people - myself included - dislike > >> the idea of hierarchical namespaces. The *dot* in the name has no > semantics > >> it's just a separator. The name could equally well be > encoders.mpg.erlyvideo > >> or mpg.applications.erlvideo.encoder - there is no logical way to > organise the > >> package name and it does not scale - > > > > packages are NOT in Erlang? Then the related code should be removed > because > > erl.lang.number:plus(1, 1) definitely works. > > > > Also, I think the Haskell guys would disagree about packages not scaling. > > > > -- > > Anthony Ramine > > Dev:Extend > > http://dev-extend.eu > > > > > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > - -- > Parnell "ixmatus" Springmeyer (http://ixmat.us) > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > > iQEcBAEBAgAGBQJN29UaAAoJEPvtlbpI1POLpSAH/ijpOgfq1F+AF140/aXZke6C > EXrWaiFBOgna0lkKu4lmwusOebLbyoiPs9D9vstlVff7npZ4Zdw32fp9LRuBjwfY > rgGesMBoUGNMtpzXuuduCH7CkZNCIrBXj8uvKOBlDxt5csOz8FCpxvKDOXZg/z0I > bFMP0HTYj1pzC2ixk2RmlUdKdbMLCCriIU+n0R5f4lIEck1FcoDm233ZHv1Sv9QC > 9PlQ4kF91H/CavPAdD/JX4sDp6NRTCjV/VWCUzDTOyK/11/fl4R7nAB61TXzkVmz > tv3y5z5RCkfjlatgvGSQ3d9vRbSn5fQneguxMX54JHI0WTEcWZ3xCQZZ8QKPuhY= > =Faf+ > -----END PGP SIGNATURE----- > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Tue May 24 20:16:20 2011 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 24 May 2011 20:16:20 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: <9ED39284-56EE-4FA3-9985-C806339BEAB4@dev-extend.eu> Message-ID: On Tue, May 24, 2011 at 6:54 PM, Tom Murphy wrote: > On 5/24/11, Parnell Springmeyer wrote: > > In practice though, I would really hate maintaining the metadata for > > every function I've wrote! I much rather group common functions into a > > module and then annotate the module with metadata. > > Ideally, it wouldn't just be just you maintaining the metadata - if > the functions were in the centralized DB, others could suggest or make > changes, wikipedia-style. > This did occur to me - the wikipedia allows large numbers of people to make small contributions. Think of what I want as a wiki where each entry is a single erlang function. > > Tom > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthonym@REDACTED Tue May 24 20:33:58 2011 From: anthonym@REDACTED (Anthony Molinaro) Date: Tue, 24 May 2011 11:33:58 -0700 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: <9ED39284-56EE-4FA3-9985-C806339BEAB4@dev-extend.eu> Message-ID: <20110524183358.GA69260@alumni.caltech.edu> I'm wondering if a wiki, and an interface to construct a module (similar to those available for javascript libs like YUI/JQuery), wouldn't get you most of what you want. So I imagine being able to share individual functions from your own misc lib, and then constructing misc libs with the set of functions you want, maybe when the addition of a module name. This means you can still use the module name as a method of encapsulation but you can construct a module from a collection of functions. You might even make it such that you can start to define modules in a local file via a description language or set of compiler directives as well as providing a web interface for constructing these modules. So maybe you could do something like -module(lists2). -remote("http://erlfshare.com/?author=joe&func=remove_duplicates", dedup/2). -remote("http://erlfshare.com/?author=joe&func=list2frequency_distribution", freq/1). And that would be the definition of the lists2 module in your codebase, it could pull the functions from the shared repo at compile time. If you want to be safe you could version everything and pull in particular versions or hide the url construction, and instead have a proplist you set values in. At the very least this allows you to share functions and work with pre-existing code. Just a thought, -Anthony On Tue, May 24, 2011 at 08:16:20PM +0200, Joe Armstrong wrote: > On Tue, May 24, 2011 at 6:54 PM, Tom Murphy wrote: > > > On 5/24/11, Parnell Springmeyer wrote: > > > In practice though, I would really hate maintaining the metadata for > > > every function I've wrote! I much rather group common functions into a > > > module and then annotate the module with metadata. > > > > Ideally, it wouldn't just be just you maintaining the metadata - if > > the functions were in the centralized DB, others could suggest or make > > changes, wikipedia-style. > > > > This did occur to me - the wikipedia allows large numbers of people > to make small contributions. Think of what I want as a wiki where each > entry is a single erlang function. > > > > > > > > Tom > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- ------------------------------------------------------------------------ Anthony Molinaro From watson.timothy@REDACTED Tue May 24 20:36:37 2011 From: watson.timothy@REDACTED (Tim Watson) Date: Tue, 24 May 2011 19:36:37 +0100 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: <9ED39284-56EE-4FA3-9985-C806339BEAB4@dev-extend.eu> Message-ID: I'd like to propose a "step in the right direction", which won't go the whole hog in terms of what Joe is proposing, but would certainly move us in (what IMHO is) a good direction and potentially towards Joe's vision if he wants to go that far. I know it isn't the whole hog, but maybe it's a useful increment towards where we'd like to be. Why don't we start by building a search engine for finding Erlang "stuff" such as OTP applications/libraries, modules and functions. I would propose that we allow users to search for things by - kind (e.g., process/gen_thing, modules, functions, whole applications) - category (set of arbitrary tags?) - type signature (i.e., spec) I'm guessing this will require patching the compiler to preserve the type specs in the beam code. That is something I would need help with, but may be trivial for others. The other things I think you might want are (in no particular order): 1. binary (code) artefact repository (presumably with a REST/web interface?) 2. an means of uploading artefacts (tarballs? .ez archives?) to the repository 3. library code for introspecting module metadata (e.g., pulling type specs from beam code) 4. some means of annotating packages/modules/functions with metadata outside of the beam code 5. search (indexing, etc) capabilities 6. a way to obtain the *things* that you've identified as being useful to you Not everything will need to be built from scratch. Binary (code) artefact repositories already exist (to some extent) in the form of CEAN (which has version 2.0 coming out soon IIRC) and the Erlware repository. Those tools may not be immediately fit for re-use as they come with baggage, but they may be a good base upon which to build something for starters. Other things/ideas might be: - Integration with build tools (such as rebar) would be useful. - Integration with existing search/package-mgmt tools such as agner You could easily write a plugin that uses epm/agner/sutro to search github for something that isn't in the repo, pulls it, builds it and adds it. So many possibilities. I do have other projects on the go, and a job, a family and even a social life! Nonetheless, I would be happy to contribute to an initiative such as this (or something similarly incremental). On 24 May 2011 19:16, Joe Armstrong wrote: > > > On Tue, May 24, 2011 at 6:54 PM, Tom Murphy wrote: >> >> On 5/24/11, Parnell Springmeyer wrote: >> > In practice though, I would really hate maintaining the metadata for >> > every function I've wrote! I much rather group common functions into a >> > module and then annotate the module with metadata. >> >> Ideally, it wouldn't just be just you maintaining the metadata - if >> the functions were in the centralized DB, others could suggest or make >> changes, wikipedia-style. > > This did occur to me - the wikipedia allows large numbers of people > to make small contributions. Think of what I want as a wiki where each > entry is a single erlang function. > > > >> >> Tom >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > From watson.timothy@REDACTED Tue May 24 20:40:49 2011 From: watson.timothy@REDACTED (Tim Watson) Date: Tue, 24 May 2011 19:40:49 +0100 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: <9ED39284-56EE-4FA3-9985-C806339BEAB4@dev-extend.eu> Message-ID: On this note Joe, in terms of moving the right direction... My thoughts were that once you've got all that beam code indexed and/or in memory, it's not a huge step to do what you want because the underlying infrastructure is already there. Also I see the approach you're proposing as being a complimentary and/or alternative to the current status quo, so folks wanting to carry on as-is will simply make use of the search+download capabilities without utilising the *edit my code like its a wiki page* features and so on. On 24 May 2011 19:36, Tim Watson wrote: > I'd like to propose a "step in the right direction", which won't go > the whole hog in terms of what Joe is proposing, but would certainly > move us in (what IMHO is) a good direction and potentially towards > Joe's vision if he wants to go that far. I know it isn't the whole > hog, but maybe it's a useful increment towards where we'd like to be. > > Why don't we start by building a search engine for finding Erlang > "stuff" such as OTP applications/libraries, modules and functions. > > I would propose that we allow users to search for things by > > - kind (e.g., process/gen_thing, modules, functions, whole applications) > - category (set of arbitrary tags?) > - type signature (i.e., spec) > > I'm guessing this will require patching the compiler to preserve the > type specs in the beam code. That is something I would need help with, > but may be trivial for others. > > The other things I think you might want are (in no particular order): > > 1. binary (code) artefact repository (presumably with a REST/web interface?) > 2. an means of uploading artefacts (tarballs? .ez archives?) to the repository > 3. library code for introspecting module metadata (e.g., pulling type > specs from beam code) > 4. some means of annotating packages/modules/functions with metadata > outside of the beam code > 5. search (indexing, etc) capabilities > 6. a way to obtain the *things* that you've identified as being useful to you > > Not everything will need to be built from scratch. Binary (code) > artefact repositories already exist (to some extent) in the form of > CEAN (which has version 2.0 coming out soon IIRC) and the Erlware > repository. Those tools may not be immediately fit for re-use as they > come with baggage, but they may be a good base upon which to build > something for starters. > > Other things/ideas might be: > > - Integration with build tools (such as rebar) would be useful. > - Integration with existing search/package-mgmt tools such as agner > > You could easily write a plugin that uses epm/agner/sutro to search > github for something that isn't in the repo, pulls it, builds it and > adds it. So many possibilities. > > I do have other projects on the go, and a job, a family and even a > social life! Nonetheless, I would be happy to contribute to an > initiative such as this (or something similarly incremental). > > > On 24 May 2011 19:16, Joe Armstrong wrote: >> >> >> On Tue, May 24, 2011 at 6:54 PM, Tom Murphy wrote: >>> >>> On 5/24/11, Parnell Springmeyer wrote: >>> > In practice though, I would really hate maintaining the metadata for >>> > every function I've wrote! I much rather group common functions into a >>> > module and then annotate the module with metadata. >>> >>> Ideally, it wouldn't just be just you maintaining the metadata - if >>> the functions were in the centralized DB, others could suggest or make >>> changes, wikipedia-style. >> >> This did occur to me - the wikipedia allows large numbers of people >> to make small contributions. Think of what I want as a wiki where each >> entry is a single erlang function. >> >> >> >>> >>> Tom >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > From amphibian.ltd@REDACTED Tue May 24 20:53:13 2011 From: amphibian.ltd@REDACTED (Tim Carpenter) Date: Tue, 24 May 2011 19:53:13 +0100 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: <20110524183358.GA69260@alumni.caltech.edu> References: <9ED39284-56EE-4FA3-9985-C806339BEAB4@dev-extend.eu> <20110524183358.GA69260@alumni.caltech.edu> Message-ID: <3A8286D3-A8D2-4107-A645-9A59CBFB1CBE@gmail.com> The module from a collection of functions is basically along the lines I was thinking, but with the ability to expose to the users of that module simpler, unchanging or changing names depending on the way the module is used. Sent from my iPhone On 24 May 2011, at 19:33, Anthony Molinaro wrote: > I'm wondering if a wiki, and an interface to construct a module (similar to > those available for javascript libs like YUI/JQuery), wouldn't get you most > of what you want. > > So I imagine being able to share individual functions from your own > misc lib, and then constructing misc libs with the set of functions > you want, maybe when the addition of a module name. > > This means you can still use the module name as a method of encapsulation > but you can construct a module from a collection of functions. > > You might even make it such that you can start to define modules in a > local file via a description language or set of compiler directives as > well as providing a web interface for constructing these modules. > > So maybe you could do something like > > -module(lists2). > > -remote("http://erlfshare.com/?author=joe&func=remove_duplicates", > dedup/2). > -remote("http://erlfshare.com/?author=joe&func=list2frequency_distribution", > freq/1). > > And that would be the definition of the lists2 module in your codebase, > it could pull the functions from the shared repo at compile time. If > you want to be safe you could version everything and pull in particular > versions or hide the url construction, and instead have a proplist you > set values in. > > At the very least this allows you to share functions and work with > pre-existing code. > > Just a thought, > > -Anthony > > On Tue, May 24, 2011 at 08:16:20PM +0200, Joe Armstrong wrote: >> On Tue, May 24, 2011 at 6:54 PM, Tom Murphy wrote: >> >>> On 5/24/11, Parnell Springmeyer wrote: >>>> In practice though, I would really hate maintaining the metadata for >>>> every function I've wrote! I much rather group common functions into a >>>> module and then annotate the module with metadata. >>> >>> Ideally, it wouldn't just be just you maintaining the metadata - if >>> the functions were in the centralized DB, others could suggest or make >>> changes, wikipedia-style. >>> >> >> This did occur to me - the wikipedia allows large numbers of people >> to make small contributions. Think of what I want as a wiki where each >> entry is a single erlang function. >> >> >> >> >>> >>> Tom >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> > >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > > -- > ------------------------------------------------------------------------ > Anthony Molinaro > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From jack@REDACTED Tue May 24 20:53:29 2011 From: jack@REDACTED (Jack Moffitt) Date: Tue, 24 May 2011 12:53:29 -0600 Subject: [erlang-questions] System timers, now/0, and instrumentation In-Reply-To: References: <673380092.213661306227737701.JavaMail.root@zimbra> Message-ID: > Breaks compatibility (backwards and cross platform.) I'm not talking about changing the semantics, just the implementation. If anything, it's currently incompatible across platform according to the original poster. I understand it may break Windows compatibility with older Erlangs, but making it work correctly on the platform seems like it would be a good goal. In other words, it sounds to me that it is simply a bug that the Windows Erlang doesn't use high resolution timers on the platform when they are readily available. jack. From octopusfluff@REDACTED Tue May 24 20:59:54 2011 From: octopusfluff@REDACTED (Amy Lear) Date: Tue, 24 May 2011 11:59:54 -0700 Subject: [erlang-questions] System timers, now/0, and instrumentation In-Reply-To: References: <673380092.213661306227737701.JavaMail.root@zimbra> Message-ID: On Tue, May 24, 2011 at 11:53 AM, Jack Moffitt wrote: > > Breaks compatibility (backwards and cross platform.) > > I'm not talking about changing the semantics, just the implementation. > If anything, it's currently incompatible across platform according to > the original poster. I understand it may break Windows compatibility > with older Erlangs, but making it work correctly on the platform seems > like it would be a good goal. In other words, it sounds to me that it > is simply a bug that the Windows Erlang doesn't use high resolution > timers on the platform when they are readily available. > The question is whether they are readily available. Sub-ms resolution timers appear to be 'an exercise for the reader' for Windows developers, rather than an OS-provided tool. I would agree that since I did my testing on this between a Windows machine and a Mac, cross-platform compatibility is a bit of a question mark here. I currently don't have a Linux install available to me; I presume it provides now/0 resolution in the microsecond range as well? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jack@REDACTED Tue May 24 21:09:50 2011 From: jack@REDACTED (Jack Moffitt) Date: Tue, 24 May 2011 13:09:50 -0600 Subject: [erlang-questions] System timers, now/0, and instrumentation In-Reply-To: References: <673380092.213661306227737701.JavaMail.root@zimbra> Message-ID: > The question is whether they are readily available. Sub-ms resolution timers > appear to be 'an exercise for the reader' for Windows developers, rather > than an OS-provided tool. QueryPerformanceCounter() is pretty readily available as far as I remember. Here's something Google brought up for implementing microsecond timers with it: http://www.decompile.com/cpp/faq/windows_timer_api.htm It's been a long time since I did Windows API stuff. jack. From francesco@REDACTED Tue May 24 21:30:42 2011 From: francesco@REDACTED (Francesco Cesarini) Date: Tue, 24 May 2011 20:30:42 +0100 Subject: [erlang-questions] Erlang Factory London (June 9th&10th) - Early Bird Deadline Today Message-ID: <4DDC0762.80701@erlang-solutions.com> Hi All, a note to remind you that tonight is the early bird deadline for the Erlang Factory in London June 9th and 10th. With over 50 speakers, 40 talks, 6 tracks and 5 courses, this is going to be the largest Erlang feast in Europe, equal only to the conference we ran in the US this March: http://www.erlang-factory.com/conference/London2011/programme/34 We have speakers from companies such as Basho, Ericsson, AOL, Yahoo!, WMware, Heroku and Erlang Solutions. Speakers include Erlang co-inventors Mike Williams and Robert Virding, Matthew Sackman, who worked on the first RabbitMQ prototype, Tony Falco and Scott Lystig Fritche on Riak, Kresten Krab of Erjang fame, Ulf Wiger and Adam Lindberg from ESL, Bob Ippolito, creator of Mochi Web, and Steve Vinoski, yaws and distributed systems guru. I could go on, as everyone deserves a mention, but you are better off having a look at the speaker list yourselves. Themes this year are Erlang in databases, embedded, Erlang in gaming, and test driven development. Lots of it! And for the first time, we are introducing a Business Track which looks at the advantages of Erlang from a social and economical point of view (read non-technical). All (well, almost. We are chasing the last abstracts) of the talks are listed here: http://www.erlang-factory.com/conference/London2011/talks At 12am Samoa Local Time, the early bird rate giving you a savings of 100 GBP on the full price will finish. As of today, we have more registered delegates than last year. There are also a few places at the University, with 4 3-day training courses prior to the conference, but not many. So if you are considering attending, register asap: https://www.erlang-factory.com/conference/London2011/register Rumors have it Joe will be there (reuniting the three original inventors), and that Mike will be wearing a tie. Be there to find out! Francesco -- Erlang Solutions Ltd. http://www.erlang-solutions.com From octopusfluff@REDACTED Tue May 24 22:01:03 2011 From: octopusfluff@REDACTED (Amy Lear) Date: Tue, 24 May 2011 13:01:03 -0700 Subject: [erlang-questions] System timers, now/0, and instrumentation In-Reply-To: References: <673380092.213661306227737701.JavaMail.root@zimbra> Message-ID: On Tue, May 24, 2011 at 12:24 PM, Roger Critchlow wrote: > This is actually POSIX standard, so it should be available at some > resolution for MacOS and Windows. > Windows is decidedly not POSIX compliant in many, many ways, and sometimes seems to delight in not being POSIX complaint. Your code snippet won't work as expected on all POSIX compliant systems, either; some of them have the higher resolution clocks in system-specific calls. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu55@REDACTED Tue May 24 22:02:00 2011 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Tue, 24 May 2011 22:02:00 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: <9ED39284-56EE-4FA3-9985-C806339BEAB4@dev-extend.eu> Message-ID: One thought: modules as grouping of functions and as a unit of loading are a way to ensure that a set of functions are consistent with each other, relative to some data the they can work on. This is important. Whatever replaces them should still fullfill that requirement. regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Tue May 24 22:08:40 2011 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 24 May 2011 22:08:40 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: <9ED39284-56EE-4FA3-9985-C806339BEAB4@dev-extend.eu> Message-ID: On Tue, May 24, 2011 at 8:36 PM, Tim Watson wrote: > I'd like to propose a "step in the right direction", which won't go > the whole hog in terms of what Joe is proposing, but would certainly > move us in (what IMHO is) a good direction and potentially towards > Joe's vision if he wants to go that far. I know it isn't the whole > hog, but maybe it's a useful increment towards where we'd like to be. > Why don't we start by building a search engine for finding Erlang > "stuff" such as OTP applications/libraries, modules and functions. > > YES - I've made a start on this - the first program is a segmenter that attempts to destruct a module. I've just bough a synology DS411 slim with 3TB of RAID 5 storage so am (finally) writing a backup program, this has first priority in the hobby dept. Then I have to attack my legacy collection of 40K erlang modules :-) Unfortunately information about individual functions is scattered all over the place. I want the source, the type signature, the documentation. These are available in a variety of different formats in different places. Documentation is in untagged comments in @tagged edoc format or in XML in a completely different file. I'd like this in one place with defined abstract types for everything Volunteers .... Silly design question: if multiple people can edit (say) a wiki of functions what formatting standards should be enforced? - the last person who edited the text - some "moderator" (who) - by a pretty printer (is there a *really good* pp? - with color syntax marking) > I would propose that we allow users to search for things by > > - kind (e.g., process/gen_thing, modules, functions, whole applications) > - category (set of arbitrary tags?) > - type signature (i.e., spec) > > I'm guessing this will require patching the compiler to preserve the > type specs in the beam code. That is something I would need help with, > but may be trivial for others. > Easy - it is there already (I think) poke around in beam_lib.erl this analyses the .beam files. > > The other things I think you might want are (in no particular order): > > 1. binary (code) artefact repository (presumably with a REST/web > interface?) > 2. an means of uploading artefacts (tarballs? .ez archives?) to the > repository > 3. library code for introspecting module metadata (e.g., pulling type > specs from beam code) > 4. some means of annotating packages/modules/functions with metadata > outside of the beam code > 5. search (indexing, etc) capabilities > 6. a way to obtain the *things* that you've identified as being useful to > you > > Not everything will need to be built from scratch. Binary (code) > artefact repositories already exist (to some extent) in the form of > CEAN (which has version 2.0 coming out soon IIRC) and the Erlware > repository. Those tools may not be immediately fit for re-use as they > come with baggage, but they may be a good base upon which to build > something for starters. > > Other things/ideas might be: > > - Integration with build tools (such as rebar) would be useful. > - Integration with existing search/package-mgmt tools such as agner > > You could easily write a plugin that uses epm/agner/sutro to search > github for something that isn't in the repo, pulls it, builds it and > adds it. So many possibilities. > > I do have other projects on the go, and a job, a family and even a > social life! Nonetheless, I would be happy to contribute to an > initiative such as this (or something similarly incremental). > > Great I'll be back ... /Joe > On 24 May 2011 19:16, Joe Armstrong wrote: > > > > > > On Tue, May 24, 2011 at 6:54 PM, Tom Murphy wrote: > >> > >> On 5/24/11, Parnell Springmeyer wrote: > >> > In practice though, I would really hate maintaining the metadata for > >> > every function I've wrote! I much rather group common functions into a > >> > module and then annotate the module with metadata. > >> > >> Ideally, it wouldn't just be just you maintaining the metadata - if > >> the functions were in the centralized DB, others could suggest or make > >> changes, wikipedia-style. > > > > This did occur to me - the wikipedia allows large numbers of people > > to make small contributions. Think of what I want as a wiki where each > > entry is a single erlang function. > > > > > > > >> > >> Tom > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questions@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-questions > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From octopusfluff@REDACTED Tue May 24 22:08:54 2011 From: octopusfluff@REDACTED (Amy Lear) Date: Tue, 24 May 2011 13:08:54 -0700 Subject: [erlang-questions] System timers, now/0, and instrumentation In-Reply-To: References: <673380092.213661306227737701.JavaMail.root@zimbra> Message-ID: On Tue, May 24, 2011 at 12:09 PM, Jack Moffitt wrote: > > The question is whether they are readily available. Sub-ms resolution > timers > > appear to be 'an exercise for the reader' for Windows developers, rather > > than an OS-provided tool. > > QueryPerformanceCounter() is pretty readily available as far as I > remember. Here's something Google brought up for implementing > microsecond timers with it: > http://www.decompile.com/cpp/faq/windows_timer_api.htm > > It's been a long time since I did Windows API stuff. > Thanks, that's very interesting. That could be used on a per-project basis for some simple profiling, but is there any chance of the Erlang profiling tools making use of this or something like this? Ideally, one should be able to expect the same tools to function roughly the same on each platform when they APPEAR to function and the requisite infrastructure is present for them to perform equivalently. -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Tue May 24 22:23:38 2011 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 24 May 2011 22:23:38 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: <9ED39284-56EE-4FA3-9985-C806339BEAB4@dev-extend.eu> Message-ID: On Tue, May 24, 2011 at 10:02 PM, Vlad Dumitrescu wrote: > One thought: modules as grouping of functions and as a unit of loading are > a way to ensure that a set of functions are consistent with each other, > relative to some data the they can work on. This is important. Whatever > replaces them should still fullfill that requirement. > > regards, > Vlad > > Absolutly. I'm working on the idea of flows. A flow is a list of flows or grains A grain is an atomic thing A module is basically a flow where the grains are functions. A novel is a flow of " chapter flows" a "chapter flow" is a flow of paragraph grains etc. An image gallery is a flow of image grains. Everything is a flow or a grain. I'm wriiting a folding editor in javascript to support editing/organising flows I made a weak minded attempt at this see https://github.com/joearms/elib1/tree/master/unsupported/folding In this directory are some rudimentary folding editors test_js6.html and experiment.erl are fun. (( If anybody reading this is an ace javascript hacker and wants to help please mail me -- I know *exactly* what help I need)) My first goal is to segement modules into flows and put them into a web based flow editor. All the flows will be in a global database. One thing I missed saying - associated with each function is *research* (NOT documentation) I want to store all reserach notes necessary to write the function along with the function in a hidden fold this should contain text, PDFs images etc. - the lot. Often the research to write 100 lines of codes takes weeks and we throw all this away - this must be stored with the code (NOT linked, store a copy, the link might be dead years later) /Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From raould@REDACTED Tue May 24 22:42:28 2011 From: raould@REDACTED (Raoul Duke) Date: Tue, 24 May 2011 13:42:28 -0700 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: On Tue, May 24, 2011 at 1:06 AM, Joe Armstrong wrote: > When I'm programming I often get to the point were I say there should > a function foo/2 in lists.erl but their isn't. There should be but > there isn't - foo/2 is a small self contained thing. Why should it be > in lists.erl because it "feels right". that Open-Closed thing, and suck elk, is just never that easy no matter what the paradigm? sincerely. From erlang@REDACTED Tue May 24 22:48:23 2011 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 24 May 2011 22:48:23 +0200 Subject: [erlang-questions] Erlang Factory London (June 9th&10th) - Early Bird Deadline Today In-Reply-To: <4DDC0762.80701@erlang-solutions.com> References: <4DDC0762.80701@erlang-solutions.com> Message-ID: On Tue, May 24, 2011 at 9:30 PM, Francesco Cesarini < francesco@REDACTED> wrote: > Hi All, > > a note to remind you that tonight is the early bird deadline for the Erlang > Factory in London June 9th and 10th. With over 50 speakers, 40 talks, 6 > tracks and 5 courses, this is going to be the largest Erlang feast in > Europe, equal only to the conference we ran in the US this March: > > http://www.erlang-factory.com/conference/London2011/programme/34 > > We have speakers from companies such as Basho, Ericsson, AOL, Yahoo!, > WMware, Heroku and Erlang Solutions. Speakers include Erlang co-inventors > Mike Williams and Robert Virding, Matthew Sackman, who worked on the first > RabbitMQ prototype, Tony Falco and Scott Lystig Fritche on Riak, Kresten > Krab of Erjang fame, Ulf Wiger and Adam Lindberg from ESL, Bob Ippolito, > creator of Mochi Web, and Steve Vinoski, yaws and distributed systems guru. > I could go on, as everyone deserves a mention, but you are better off > having a look at the speaker list yourselves. Themes this year are Erlang in > databases, embedded, Erlang in gaming, and test driven development. Lots of > it! And for the first time, we are introducing a Business Track which looks > at the advantages of Erlang from a social and economical point of view (read > non-technical). All (well, almost. We are chasing the last abstracts) of the > talks are listed here: > > http://www.erlang-factory.com/conference/London2011/talks > > At 12am Samoa Local Time, the early bird rate giving you a savings of 100 > GBP on the full price will finish. As of today, we have more registered > delegates than last year. There are also a few places at the University, > with 4 3-day training courses prior to the conference, but not many. So if > you are considering attending, register asap: > > https://www.erlang-factory.com/conference/London2011/register > > Rumors have it Joe will be there (reuniting the three original inventors), > and that Mike will be wearing a tie. > Hello Mike Hello Robert /Joe > > Be there to find out! > > Francesco > > -- > Erlang Solutions Ltd. > http://www.erlang-solutions.com > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james@REDACTED Tue May 24 22:56:41 2011 From: james@REDACTED (James Aimonetti) Date: Tue, 24 May 2011 13:56:41 -0700 Subject: [erlang-questions] Upcoming San Francisco ErLounge - Wed 25th @ Heroku In-Reply-To: References: <4DDA96E8.5090109@2600hz.com> Message-ID: <4DDC1B89.7000907@2600hz.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Orion, Thanks again for hosting. 7pm was the time on the Meetup (http://www.meetup.com/ErLounge/events/19410211/). See you tomorrow evening, James On 05/24/2011 09:55 AM, Orion Henry wrote: > Do we have a final word on this? Would love to know what time to expect > everyone. Evening I'm assuming? 5? 6? > > On Mon, May 23, 2011 at 10:18 AM, James Aimonetti wrote: > >> The Heroku folks have offered to host an ErLounge at their offices >> Wednesday evening. >> >> We haven't been able to get in touch with the Meetup organizer, so I''m >> posting this here in hopes that folks will see it and we can get it added to >> the calendar. >> >> The offices are located at 321 11th St, San Francisco (near Folsom). >> Orion, if you want to provide more details for parking, buses, time, etc, >> that'd be great. >> >> Sorry for the short notice; hope to see folks there to learn about how >> Heroku uses Erlang and general Erlang discussion. >> >> I'll be bringing two others with me for sure, possibly a third. >> >> -- >> James Aimonetti >> Distributed Systems Engineer / DJ MC_ >> >> 2600hz | http://2600hz.comsip:james@REDACTED >> tel: 415.886.7905 >> >> > - -- James Aimonetti Distributed Systems Engineer / DJ MC_ 2600hz | http://2600hz.com sip:james@REDACTED tel: 415.886.7905 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJN3BuIAAoJENc77s1OYoGggcIIAJ5gur1gvBNaTm3aln4xlM4U j7B+jo+eurmrCCzyL0lNTo2X/gGRSr0iaIsuX7UN838cS8NiQrS75W8jGvp2ewim MXgHcYVULLpd2/M2ccwyYHCFuUdkS0GxyMZ3JwAwsrNaKLcBGgFSAqVhEpiK8NU5 5mFBIAdyi4Yolk4UjRJStNVjvvpxoGiAxspCATme8cGiLkgBa3RQ4f94Ef1pZR8M qXJdJVmbFFP0fw7ZA4n7no26OHsVoiKu/+81l/aBxXBa2pH9u+b7I8HwmLlJdnv8 DN/0hTab4ofVf94gXhGjDl+JE+AZt9OOLILUYKr2sVqrQ/PicdzLtK2u/X1D/wA= =qoHQ -----END PGP SIGNATURE----- From moxford@REDACTED Tue May 24 23:14:23 2011 From: moxford@REDACTED (Mike Oxford) Date: Tue, 24 May 2011 14:14:23 -0700 Subject: [erlang-questions] Erlang Factory London (June 9th&10th) - Early Bird Deadline Today In-Reply-To: References: <4DDC0762.80701@erlang-solutions.com> Message-ID: > > >> Rumors have it Joe will be there (reuniting the three original inventors), >> and that Mike will be wearing a tie. >> > > Hello Mike > Hello Robert > > /Joe > Joe, you forgot the requisite Monty Python-ish skit... http://www.youtube.com/watch?v=qyVvGjNjBOA&feature=player_detailpage#t=231s Fixed. -mox -------------- next part -------------- An HTML attachment was scrubbed... URL: From antoine.koener@REDACTED Wed May 25 00:23:52 2011 From: antoine.koener@REDACTED (Antoine Koener) Date: Wed, 25 May 2011 00:23:52 +0200 Subject: [erlang-questions] esmtp: send PDF as an attachment In-Reply-To: <1306255968.27369.156.camel@cag0001w798> References: <22D4C8B4-9E83-4380-A9A9-06D0E871107F@gmail.com> <1306255968.27369.156.camel@cag0001w798> Message-ID: Some thoughts: On May 24, 2011, at 18:52 , Amancio D?az Su?rez wrote: > {ok, PngContent0} = file:read_file(?MAIL_PNG_LOGO), > PngContent1 = base64:encode(PngContent0), > PngContent = erlang:binary_to_list(PngContent1), Are you sure that you need to build a List ? From jeffm@REDACTED Wed May 25 02:58:46 2011 From: jeffm@REDACTED (jm) Date: Wed, 25 May 2011 10:58:46 +1000 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: <4AA969E9-93F7-4E0F-8C36-E784D83F3F18@trifork.com> Message-ID: <4DDC5446.8030800@ghostgun.com> On 24/05/11 9:25 PM, Joe Armstrong wrote: > > If we think of modules as containers of functions, then a module is a > "set of functions" - > my problem is with granularity. The smallest unit of reuse is the > module. Suppose my application > want just one function from a particular module - I'm forced to load > the entire module. > > This hampers reuse - I *often* read library code and find a single > function and cut-and-paste it into > my new code. It also discourages sharing - since the smallest unit I > can share is a module. > > The unit of distribution is an application - a set of modules - why > this could not be a list of functions > I do not know. > > I think I'd like to view an application as something that offered a > message based service that internally > was constructed from a set of functions rather than a set of modules. > Here's a "mad hatter" suggestion. Introduce the concept of a "shadow" module. For example, say your using the list module and your after a lists:randomise/1. In this proposal you'd have your own lists module, say joes_lists, -module(joes_lists) randomise(List) -> %% code to randomise the order of the list In you code you would then say, -shadows(joes_lists, lists). then use lists:randomise(AList) in your code. The compiler would first check the lists module and if the required function didn't exist it would use your modules. This would avoid you accidentially overriding the main modules definitions which may cause confusion. In such a case, the clash should be treated as a compilation error. The second part would be distribution and release management. There's several ways this could be done one would be to have a script which would build a set of "patch modules" which would be the cut down versions of your own development modules containing only the code and associated documentation your using in the current project. Actually, it might be better to include this as part of the project development: execute a script which scans your code repository and the -shadow/2 compiler directives and generates the shadow modules as needed. This could mean that your custom modules could be kept in a git or mercurial repository, on a web server, or in a key-value store. The URLs would then be part of the configuration for this script along with version tags, etc. Yes, I going to ignore how the modules get in there in the first place. Jeff. From ebegumisa@REDACTED Wed May 25 05:25:26 2011 From: ebegumisa@REDACTED (Edmond Begumisa) Date: Wed, 25 May 2011 13:25:26 +1000 Subject: [erlang-questions] QuickCheck/PropEr In-Reply-To: <39276.1306190046@snookles.snookles.com> References: <39276.1306190046@snookles.snookles.com> Message-ID: Thanks a bunch Scott. This looks like a good case-study. I will analyse it fully. Quick one: are there any properties on gen_servers in here? - Edmond - On Tue, 24 May 2011 08:34:06 +1000, Scott Lystig Fritchie wrote: > Edmond Begumisa wrote: > > eb> . and from "Testing Stateful Code" in PropEr's README. But I can't > eb> figure out how to actually write the properties with symbolic reps > eb> for the callbacks. Can anyone offer me an example on how to do this? > > Keeping in mind that these tests were written with full QuickCheck(*), > here are some stateful examples, using either eqc_statem or eqc_fsm: > > https://github.com/basho/riak_core/blob/master/test/node_watcher_qc.erl > https://github.com/slfritchie/bitcask/blob/slf-rb-tree-hack2/test/rb_eqc.erl > (Also uses eqc_c for testing C code (very fun!), namely a red-black > tree) > https://github.com/basho/bitcask/blob/master/test/bitcask_qc_fsm.erl > https://github.com/basho/riak_kv/blob/master/test/backend_eqc.erl > https://github.com/basho/riak_kv/blob/master/test/get_fsm_qc.erl > (Not using eqc_statem or eqc_fsm, but used for testing a gen_fsm > module) > > -Scott > > (*) Technically it's just "QuickCheck"? Hm, I like the sound of > "QuickCheck Jumbo" -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From ebegumisa@REDACTED Wed May 25 05:31:06 2011 From: ebegumisa@REDACTED (Edmond Begumisa) Date: Wed, 25 May 2011 13:31:06 +1000 Subject: [erlang-questions] QuickCheck/PropEr In-Reply-To: <4DDAE581.6060704@cs.ntua.gr> References: <319EB5973BAA42579692F3000F036E22@JohnsTablet2009> <4DDAE581.6060704@cs.ntua.gr> Message-ID: On Tue, 24 May 2011 08:53:53 +1000, Kostis Sagonas wrote: > Edmond Begumisa wrote: >> Thanks John, >> This was most helpful and got me over that initial hurdle. I see now >> that property-based testing is more about defining how the system >> should behave and is best used as a design-time aid -- almost like >> programming by contract. Write properties first, code from there. >> Thinking of it the other way had caused me great confusion. >> ... , I'll direct the following silly questions to PropEr users >> instead: >> * proper_fsm now makes more sense (reminds me a little of UBF(C)). But >> I'm having trouble with defining properties for my gen_servers. ... >> Thanks in advance for any help. > > > Edmond, > > Sorry, but given the upcoming OTP release I have been swamped by other > more urgent duties... I do not have any answers to your questions at > this point in time (sorry about that) Understandable. No problem. Thanks for responding. > but I would like to mention that: > > 1. We are in the process of creating a PropEr web site where among > other things there will be PropEr tutorials, examples and FAQ. > Our intention is to have it ready by the Erlang Factory in London, > so please be a bit patient. Good news. > 2. My talk in London will be about PropEr and what it can do for you: > http://www.erlang-factory.com/conference/London2011/speakers/KostisSagonas > Hope there will the usual video for those of us who can't make it. > 3. The address you are using does not reach the PropEr users but its > developers. We'll set up such a user mailing list once we properly > announce the first version of our tool -- note that it is currently > unannounced even though I am aware that it's already being used by > quite a few companies and many Erlang developers out there. > > Best, > Kostis Thanks. - Edmond - -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From ebegumisa@REDACTED Wed May 25 05:34:17 2011 From: ebegumisa@REDACTED (Edmond Begumisa) Date: Wed, 25 May 2011 13:34:17 +1000 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: Hello Joe, I've personally wanted an easy way to load modules from different places. If you started with making modules easy to load from different places, then later provide support for functions, I imagine this would be easier to implement immediately and easier for people to make use of immediately ... where "people" refers to me :) I've got two suggestions (mostly inspired by the Mozilla Framework)... 1. How about letting the programmer choose where the functions come from (kv store, fs, web-server, etc)... For instance, a module could start... -import(["file://misc/collect_int", "http://erlang.org/lists/*", "mnesia://db1/misc/merge_kv"]). By default, the code loader would know what to do when it encounters "file://", "http://", "https://", "ftp://", "sftp://" and "mnesia://" URI schemes. Programmers could be allowed define their own URI schemes by providing callbacks for loading code. For instance, one would be able to define "ubf://" and have the code loader call his/her code when it encounters "ubf://foo/bar" 2. Expanding on this: letting the programmer centralise the possible locations of modules/functions and use this to define namespaces... One possible way of doing this is to steal from the "chrome registration" system that the Mozilla Framework uses. A programmer could define one-level deep namespaces in a configuration file which points to targets that could come from anywhere, then use that in her modules. A module could then start... -import(["erlang://misc/collect_int", "erlang://couch/mapreduce"]). Where "misc" and "couch" are namespaces and "erlang://" is a special URI scheme telling the code loader to refer to the configuration file "erlang.manifest" which would contain... [{"misc", "file://./ebin/misc.beam"}, {"couch", "http://localhost:7777/ebin/"}] Where "couch" points to a yaws server serving couch beams, or something along those lines. Then she can easy switch between different code sources using one file. A code-signing system could also be introduced. - Edmond - On Tue, 24 May 2011 18:06:19 +1000, Joe Armstrong wrote: > Why do we need modules at all? > > This is a brain-dump-stream-of-consciousness-thing. I've been > thinking about this for a while. > > I'm proposing a slightly different way of programming here > The basic idea is > > - do away with modules > - all functions have unique distinct names > - all functions have (lots of) meta data > - all functions go into a global (searchable) Key-value database > - we need letrec > - contribution to open source can be as simple as > contributing a single function > - there are no "open source projects" - only "the open source > Key-Value database of all functions" > - Content is peer reviewed > > These are discussed in no particular order below: > > Why does Erlang have modules? > > There's a good an bad side to modules: > > Good: Provides a unit of compilation, a unit of code > distribution. unit of code replacement > > Bad: It's very difficult to decide which module to put an individual > function in. Break encapsulation (see later) > > Aside: lib_misc.erl > > When I'm programming I often get to the point were I say there should > a function foo/2 in lists.erl but their isn't. There should be but > there isn't - foo/2 is a small self contained thing. Why should it be > in lists.erl because it "feels right". > > Strings are lists, so why do we have two modules lists.erl and > string.erl how should I decide in which module my new string/list > processing function should go. > > To avoid all mental anguish when I need a small function that > should be somewhere else and isn't I stick it in > a module elib1_misc.erl. > > My elib1_misc exports the following: > > added_files/2 make_challenge/0 > as_bits/1 make_response/2 > as_bits_test/0 make_response_test/0 > bdump/2 make_test_strings/1 > bin2hex/1 make_test_strings_test/0 > bin2hex_test/0 make_tmp_filename/2 > check_io_list/1 merge_kv/1 > collect_atom/1 merge_kv_test/0 > collect_atom_test/0 mini_shell/0 > collect_int/1 module_info/0 > collect_int_test/0 module_info/1 > collect_string/1 ndots/1 > collect_string_test/0 nibble_to_hex_char/1 > collect_word/1 nibble_to_hex_char_test/0 > complete/2 odd/1 > complete_test/0 on_exit/2 > dos2unix/1 out_of_date/2 > downcase_char/1 outfile/2 > dump/2 padd/2 > dump_tmp/2 perms/1 > duplicates/1 perms_test/0 > ensure_started/2 pmap/2 > eval_file/1 pmap1/2 > eval_file_test/0 pmap1_test/0 > eval_string/1 pmap_test/0 > eval_string_test/0 priority_receive/0 > every/3 random_seed/0 > expand_env_vars/1 random_string/1 > expand_file_template/3 random_string/2 > expand_string_template/2 read_at_most_n_lines/2 > expand_tabs/1 read_at_most_n_lines_test/0 > expand_tabs_test/0 remove_duplicates/1 > expand_template/2 remove_duplicates_test/0 > extract_attribute/2 remove_leading_and_trailing_whitespace/1 > extract_attribute_test/0 > remove_leading_and_trailing_whitespace_test/0 > extract_prefix/2 remove_leading_whitespace/1 > fetch/2 remove_prefix/2 > fetch_test/0 remove_prefix_test/0 > file2lines/1 remove_trailing_whitespace/1 > file2lines_test/0 replace/3 > file2md5/1 root_dir/0 > file2numberedlines/1 rpc/2 > file2numberedlines_test/0 safe/1 > file2paras/1 show_loaded/1 > file2stream/1 signed_byte_to_hex_string/1 > file2string/1 signed_byte_to_hex_string_test/0 > file2template/1 skip_blanks/1 > file2term/1 skip_blanks_test/0 > file_size_and_type/1 skip_to_nl/1 > find_src/1 skip_to_nl_test/0 > first/1 sleep/1 > flatten_io_list/1 spawn_monitor/3 > flush_buffer/0 split_at_char/2 > for/3 split_at_char_test/0 > force/1 split_list/2 > foreach_chunk_in_file/3 split_list_test/0 > foreach_word_in_file/2 string2exprs/1 > foreach_word_in_string/2 string2exprs_test/0 > forever/0 string2html/1 > get_erl_section/2 string2latex/1 > get_line/1 string2lines/1 > get_line/2 string2lines_test/0 > have_common_prefix/1 string2stream/1 > have_common_prefix_test/0 string2stream_test/0 > hex2bin/1 string2template/1 > hex2bin_test/0 string2template_test/0 > hex2list/1 string2term/1 > hex2list_test/0 string2term_test/0 > hex_nibble2int/1 string2toks/1 > hex_nibble2int_test/0 string2toks_test/0 > id/1 sub_binary/3 > include_dir/0 template2file/3 > include_file/1 term2file/2 > interleave/2 term2string/1 > is_alphanum/1 test/0 > is_blank_line/1 test1_test/0 > is_prefix/2 test_function_over_substrings/2 > is_prefix_test/0 tex2pdf/1 > is_response_correct/3 time_fun/2 > keep_alive/2 time_stamp/0 > lines2para/1 to_lower/1 > list2frequency_distribution/1 to_lower_test/0 > list2frequency_distribution_tetrim/1 > longest_common_prefix/1 trim_test/0 > longest_common_prefix_test/0 unconsult/2 > lookup/2 unsigned_byte_to_hex_string/1 > lorem/1 unsigned_byte_to_hex_string_test/0 > ls/1 which/1 > which_added/1 > > Now I find this very convenient when I write a new small utility function > I stick in in elib1_misc.erl - no mental anguish in choosing a module > name is involved. > > The observation that I find this very-convenient is telling me something > about modules - I like my elib1_misc it feels right. > > (aside - It seems many development projects have their own private > lib_miscs ...) > > Which brings me to the point of my question. > > Do we need module's at all? Erlang programs are composed of lots of small > functions, the only place where modules seem useful is to hide a letrec. > > The classic example is fibonacci. We want to expose fib/1 but hide the > helper function fib/3. Using modules we say > > -module(math). > -export([fib/1]). > > fib(N) -> > fib(N, 1, 0). > > fib(N, A, B) when N < 2 -> A; > fib(N, A, B) -> fib(N-1, A+B, A). > > The downside is we have had to *invent* one module name math - whose > *only* > purpose is to hide the definition of fib/3 which we don't want to be made > callable. > > If we put a second function into the module math, then this second > function > could call fib/3 which breaks the encapsulation of fib/3. > > We could say: > > let fib = fun(N) -> fib(N, 1, 0) end > in > fib(N, A, B) when N < 2 -> A; > fib(N, A, B) -> fib(N-1, A+B, A). > end. > > I hardly dare suggest a syntax for this since I've been following > another thread in this forum where syntax discussion seem to encourage > much comment. > > ** Please do suggest alternative syntax's here - but do not comment on > other peoples suggestions ... > > I would like to just talk about why we have modules. > > Another question: > > Does the idea of a module come from the idea that functions have to be > stored somewhere, so we store them in a file, and we slurp the > file (as a unit) into the system, so the file becomes a module? > > If all the files were store by themselves in a database would this > change things. > > I am thinking more and more that if would be nice to have *all* > functions in > a key_value database with unique names. > > lookup(foo,2) would get the definition foo foo/2 from a database. > > The unique names bit is interesting - is this a good idea. Qualified > names (ie names like xxx:foo/2) or (a.b.c.foo/2) sounds like a good > idea but but when I'm programming I have to invent the xxx or the > a.b.c which is very difficult. It also involves the "decision problem" > if the namespaces xxx and a.b.c already exist I have to *choose* which > to put my new function in. > > I think there might be a case for alises here joe:foo/2 could be used > while developing "joe" would expand to a horrible random local string the > real name being ab123aZwerasch123123_foo/2 but I would not be able to > publish my code or make it available to a third_part before I had > chosen a sensible name. > > (( managing namespaces seems really tricky, a lot of peoople seem > to thing that the problem goes away by adding "." 's to the name > but managing a namespace with namees like foo.bar.baz.z is just as > complex > as managing a namespace with names like foo_bar_baz_z or names like > 0x3af312a78a3f1ae123 - the problem is that we have to go from a symbolic > name like www.a.b to a reference like 123.45.23.12 - but how do we > discover > the initial name www.a.b? - there are two answers - a) we are given the > name > (ie we click on a link) - we do not know the name but we search fo it )) > > > When programs are small we can live with "just the code" in "a few > modules" the ratio of code to meta data is high. > > When programs are large we need a lot of meta-data to understand them. > > I would like to see all functions with all meta-data in a data base. > > I'd like to say: > > lookup(foo,2,Attribute) when Attribute = > > code|source|documentation|type signatures|revision > history|authors|... > > The more I think about it the more I think program development should > viewed as changing the state of a Key-Value database. > > So I imagine: > > 1) all functions have unique names > 2) there are no modules > 3) we discover the name of a function by searching metadata > describing the function in a database > 4) all public functions (think open source) are in the same > database > > We could make a system to do this. > > I think this would make open-source projects easier, since the > granularity of contribution goes down. You could contribute > a single function - not an entire application. > > (( A problem with GUT style open source projects is there is > not one database of functions, I often what one function from > this project, another function from another project -- the > granularity of reusable parts should be the individual function. > > functions are really easy to reuse > modules are more difficult to reuse > entire applications are very difficult to reuse > (Unless there are isolated through a communication channel)) > > Possible extensions. > > 1) Voting for promotion > 2) A review process > > Given a raw database will *all* functions in it - we could derive an > "approved" functions database. > > Popular functions could be moved to the approved database - the > review process would need to be discussed - so kind of peer-review/wiki > stuff. > > Comments? > > Volunteers? > > /Joe -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From ok@REDACTED Wed May 25 06:29:16 2011 From: ok@REDACTED (Richard O'Keefe) Date: Wed, 25 May 2011 16:29:16 +1200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: <429CA039-E508-4918-91E7-9E2438BD5376@cs.otago.ac.nz> On 24/05/2011, at 8:06 PM, Joe Armstrong wrote: > Why do we need modules at all? To hide data types, and to provide short names (we can import a function and not have to keep on repeating a long long name for it). I note, without recommendation either way, the existence of local in end in Standard ML, where the second lot of declarations defines things visible outside but the first lot defines things visible only inside this form. > fib(N) -> > fib(N, 1, 0). > > fib(N, A, B) when N < 2 -> A; > fib(N, A, B) -> fib(N-1, A+B, A). could be local fun fib_aux n a b = if n < 2 then a else fib_aux (n-1) (a+b) a in fun fib n = fib_aux n 1 0 end in SML. I also note that this is NOT something that SML uses instead of modules. >Does the idea of a module come from the idea that functions have to be > > stored somewhere, so we store them in a file, and we slurp the > file (as a unit) into the system, so the file becomes a module? Probably not. Smalltalk has classes, but the unit of compilation is a single method, and the unit of storage is classically a "change set" (which may involve any number of classes and methods, and may include revisions to existing classes). I also note that in the days when Interlisp-D was just that and did not include Xerox Common Lisp, you slurped a file (as a unit) into the system, but there were no modules. There are plenty of languages where a file may contain many modules, possibly nested. (SML, Ada, to name just two.) > If all the files were store by themselves in a database would this > change things. > > I am thinking more and more that if would be nice to have *all* functions in > a key_value database with unique names. In Erlang as it stands, a source file is the natural unit of version control and documentation. The idea of coping with a sea of functions all being busily revised by hundreds if not thousands of programmers acting asynchronously troubles me. Haskell has a large package library, and people can update things often, and I keep on seeing version issues in the Haskell-caf? mailing list. Can - scope of names - grain of compilation and reloading - version control - documentation - units of (program) storage be teased apart? Smalltalk seems to suggest that something along these lines might be doable. (Smalltalk methods are version controlled individually.) However, Smalltalk documentation, especially internal documentation, varies between woeful and dire. > When programs are large we need a lot of meta-data to understand them. The Xerox slogan: a program is a data base, not a listing. Interlisp-D did not strictly speaking _have_ source files. There were files with source code in them, but they were randomly accessed data bases. Thanks to macros, this did not work as well as one might hope, but it did work after a fashion. Hey, maybe this could be a way to get rid of the preprocessor! Joe, you've invented one great language, this is crazy enough to be the concept for a second one. From ok@REDACTED Wed May 25 06:38:57 2011 From: ok@REDACTED (Richard O'Keefe) Date: Wed, 25 May 2011 16:38:57 +1200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: On 24/05/2011, at 8:39 PM, Dmitrii Dimandt wrote: >> >> So I imagine: >> >> 1) all functions have unique names >> 2) there are no modules >> 3) we discover the name of a function by searching metadata >> describing the function in a database >> 4) all public functions (think open source) are in the same >> database >> >> We could make a system to do this. > > Hm... you'd still need *some* kind of modules. > > For instance, in Webmachine each resource is expected to have some, or all, of predefined public/exported functions: to_html, resource_exists, allowed_methods etc. > > So, each resource will have functions with the same name. If we move all functions to a global namespace, then how do we differentiate between these functions? Probably by naming them resource_name_function_name? Meta-data. You say "I need a function about with a ping cousin about and a pong friend about " > > Furthermore, what do we do with behaviours? A behaviour is encapsulated within a module, also with a predefined set of exported funcions (and any number of custom exported functions). In SML, a behaviour would be a functor. In some other languages, it would be a single function that took a record of anonymous functions &c and returned a record of anonymous functions. Inventing an ad hoc syntax: local <{start ~ Start, stop ~ Stop, send ~ Send, explode ~ Explode}> = some?wonderful?new?behaviour(<{ initial_state ~ 42, shut_down ~ fun (State) -> ... end, restart_policy ~ ad_infinitum, update_state ~ fun (State, Info) -> ... end }>) in what you please using Start, Stop, Send, Explode end The trick is to combine this with hot loading, and I have too many things to do today to think of something. That's what Joe is for... From ok@REDACTED Wed May 25 06:51:16 2011 From: ok@REDACTED (Richard O'Keefe) Date: Wed, 25 May 2011 16:51:16 +1200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: On 24/05/2011, at 8:49 PM, Gordon Guthrie wrote: > ...and also... > > following on from what Dimitri said while I was writing me e-mail, we > hang unit test onto modules and design them at that level of > abstraction > Right now that is clear a Really Good Thing to do. The question is whether it has to be that way, or whether it is possible to devise something better. Do the unit of documentation and the unit of testing and the unit of loading *have* to be the same thing? How would a revised system *work* in a distributed world? Back in the early days of the language Pop, the people at the Edinburgh AI department had a game. The whole machine they were using was programmed in Pop, on top of bare metal. The game goes like this: how much of the system can you zap before you have to reboot the machine? How much of a shared sea-of-functions can you update before having to revert to backups? From michael.eugene.turner@REDACTED Wed May 25 06:54:18 2011 From: michael.eugene.turner@REDACTED (Michael Turner) Date: Wed, 25 May 2011 13:54:18 +0900 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: <429CA039-E508-4918-91E7-9E2438BD5376@cs.otago.ac.nz> References: <429CA039-E508-4918-91E7-9E2438BD5376@cs.otago.ac.nz> Message-ID: If someone had told me in 1981 (when I got a taste of both Prolog and Smalltalk) that, in 2011, we'd still be editing files of code with text editors, with a strong coincidence between "module" and "code-file/header-file pair", I would have been surprised. But here we are. Is it just cultural inertia? Or is it that this way of doing things isn't really broken, just the best compromise in the best of all programming worlds? By some coincidence, Richard and I are discussing non-contiguous clauses in named functions as something that was nice in Prolog, and would be nice in Erlang. Which would suggest an even finer granularity for the database: as long as you can maintain a (partial) order of clauses for a function, clauses, not functions, might be the minimal units. I think it's worth looking very closely at how other systems tried to solve the same or similar problems (even decades ago, e.g., Smalltalk and Interlisp-D) and what problems they ran up against, and at what kind of scaffolding would make the architecture of any Erlang solution backward compatible with (most) existing Erlang development. The ideal (probably unachievable) would be that nobody would need to change anything about how they work now, while anybody who wants to take fuller advantage of the system would face no obstacles that were rationalized in the name of backward compatibility. A tall order. -michael turner On Wed, May 25, 2011 at 1:29 PM, Richard O'Keefe wrote: > On 24/05/2011, at 8:06 PM, Joe Armstrong wrote: > > > Why do we need modules at all? > > To hide data types, > and to provide short names (we can import a function > and not have to keep on repeating a long long name for it). > > I note, without recommendation either way, > the existence of > > local > > in > > end > > in Standard ML, where the second lot of declarations > defines things visible outside but the first lot > defines things visible only inside this form. > > > fib(N) -> > > fib(N, 1, 0). > > > > fib(N, A, B) when N < 2 -> A; > > fib(N, A, B) -> fib(N-1, A+B, A). > > could be > > local > fun fib_aux n a b = if n < 2 then a else fib_aux (n-1) (a+b) a > in > fun fib n = fib_aux n 1 0 > end > > in SML. I also note that this is NOT something that SML uses instead > of modules. > > >Does the idea of a module come from the idea that functions have to be > > > > stored somewhere, so we store them in a file, and we slurp the > > file (as a unit) into the system, so the file becomes a module? > > Probably not. Smalltalk has classes, but the unit of compilation is a > single method, and the unit of storage is classically a "change set" > (which may involve any number of classes and methods, and may include > revisions to existing classes). > > I also note that in the days when Interlisp-D was just that and did > not include Xerox Common Lisp, you slurped a file (as a unit) into the > system, but there were no modules. > > There are plenty of languages where a file may contain many modules, > possibly nested. (SML, Ada, to name just two.) > > > If all the files were store by themselves in a database would this > > change things. > > > > I am thinking more and more that if would be nice to have *all* functions > in > > a key_value database with unique names. > > In Erlang as it stands, a source file is the natural unit of version > control and documentation. The idea of coping with a sea of functions > all being busily revised by hundreds if not thousands of programmers > acting asynchronously troubles me. > > Haskell has a large package library, and people can update things often, > and I keep on seeing version issues in the Haskell-caf? mailing list. > > Can > - scope of names > - grain of compilation and reloading > - version control > - documentation > - units of (program) storage > be teased apart? > > Smalltalk seems to suggest that something along these lines might be > doable. (Smalltalk methods are version controlled individually.) > However, Smalltalk documentation, especially internal documentation, > varies between woeful and dire. > > > > When programs are large we need a lot of meta-data to understand them. > > The Xerox slogan: a program is a data base, not a listing. > Interlisp-D did not strictly speaking _have_ source files. > There were files with source code in them, but they were > randomly accessed data bases. Thanks to macros, this did > not work as well as one might hope, but it did work after > a fashion. > > Hey, maybe this could be a way to get rid of the preprocessor! > > Joe, you've invented one great language, this is crazy enough to > be the concept for a second one. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From watson.timothy@REDACTED Wed May 25 07:46:52 2011 From: watson.timothy@REDACTED (Tim Watson) Date: Wed, 25 May 2011 06:46:52 +0100 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: <9ED39284-56EE-4FA3-9985-C806339BEAB4@dev-extend.eu> Message-ID: > Unfortunately information about individual functions is > scattered all over the place. I want the source, the type signature, > the documentation. These are available in a variety of different > formats in different places. Documentation is in untagged comments > in @tagged edoc format or in XML in a completely different file. Yes, this is a really important part of it. Being able to slurp in Erlang projects from the file system (and github, etc), access all this information and provide it in a searchable fashion would *already* put us way ahead of the crowd in terms of discovery. > Silly design question: if multiple people can edit (say) a wiki > of functions what formatting standards should be enforced? > > ?? - the last person who edited the text > ?? - some "moderator" (who) > ?? - by a pretty printer > ??? (is there a *really good* pp? - with color syntax marking) I think there are reasonable ones around. Take a look at http://tidier.softlab.ntua.gr:20000/tidier/getstarted. I would also propose that you let the viewer configure the pp to their own preferences. Given that you're actually storing abstract code (or AST or something like that) rather than lines of source code anyway, this is just human readable representation after all. Let people view with whatever (potentially hideous) whitespace &c convention they like. >> I'm guessing this will require patching the compiler to preserve the >> type specs in the beam code. That is something I would need help with, >> but may be trivial for others. > > Easy - it is there already (I think) poke around in beam_lib.erl > this analyses the .beam files. > I was pretty sure this wasn't the case. I'll dig in to beam_lib at lunch time and have another look. From vances@REDACTED Wed May 25 07:58:50 2011 From: vances@REDACTED (Vance Shipley) Date: Wed, 25 May 2011 11:28:50 +0530 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: <9ED39284-56EE-4FA3-9985-C806339BEAB4@dev-extend.eu> Message-ID: <20110525055849.GD22828@aluminum.local> Joe, I love the idea of ditching modules files and storing functions in a data store. What I'm picturing though is that the functions are stored in their abstract syntax form (i.e. data) so that the issue of formatting standards is stripped away. You need tools which translate it in and out so that we can continue to use the editors we are familiar with but you can edit in emacs using it's bizarre indentation and I can use vim and indent with tabs. ROK can put seperators at the begging of lines, I'll see them at the end. I have long wanted to put a toolchain together which allowed me to easily store abstract syntax in the source code control system repository. The check in and check out processes would convert (pretty print) it to my personal prefernce settings. The problem with that plan seems to be with the preprocessor. It seems to me though that your plan suffers the same problem. If macros are defined at a module level, or in an include file, you'll have to deal with them when you pull the functions out of the module and stuff it into the data store. The extended syntax tree used in the erl_syntax application might be the answer. How do you deal with record definitions? -- -Vance On Tue, May 24, 2011 at 10:08:40PM +0200, Joe Armstrong wrote: } Silly design question: if multiple people can edit (say) a wiki } of functions what formatting standards should be enforced? } } - the last person who edited the text } - some "moderator" (who) } - by a pretty printer } (is there a *really good* pp? - with color syntax marking) -- -Vance From igorrs@REDACTED Wed May 25 08:00:45 2011 From: igorrs@REDACTED (Igor Ribeiro Sucupira) Date: Wed, 25 May 2011 03:00:45 -0300 Subject: [erlang-questions] Unidirectional linking? Message-ID: Suppose there is a heavy operation Op that in some cases takes so long to finish that the caller loses interest in the result and gives up. I want to perform that operation in a way that allows me to: 1) Interrupt its execution if it does not finish in N milliseconds. 2) Interrupt its execution if the calling process exits (here I'm already supposing Op has to be run in another Erlang process, due to goal 1). To implement that, it seems unidirectional linking would be needed. Is there another safe and convenient way to do it? The first idea I had was something like this: Parent = self(), Child = spawn_link(fun() -> Parent ! (catch Op) end), receive Result -> Result after N -> unlink(Child), exit(Child, timeout), timeout end. But, if Parent is killed by another process right after calling unlink, Child would be left executing. Another problem is that I don't want Parent to die if Child exits for non-timeout reasons (although it seems very unlikely in the code above, with the catch). I was now thinking of substituting unlink(Child) with process_flag(trap_exit, true) and then kill Child, receive its exit message, set trap_exit to false again (I'm assuming it was false), and finally check if there were other exit messages (suiciding if it was the case). But then the code would become too ugly, so I got lazy and decided to post to this list. :-) What do you think? Thanks. Igor. From ebegumisa@REDACTED Wed May 25 08:07:57 2011 From: ebegumisa@REDACTED (Edmond Begumisa) Date: Wed, 25 May 2011 16:07:57 +1000 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: <429CA039-E508-4918-91E7-9E2438BD5376@cs.otago.ac.nz> References: <429CA039-E508-4918-91E7-9E2438BD5376@cs.otago.ac.nz> Message-ID: On Wed, 25 May 2011 14:29:16 +1000, Richard O'Keefe wrote: > On 24/05/2011, at 8:06 PM, Joe Armstrong wrote: > >> Why do we need modules at all? > > To hide data types, What are the possible ways of dealing with this? When you break modules up into individual functions? I presume such a system would therefore need a way of importing types (complete with versioning) in addition to functions. Which would then introduce additional complexity for the programmer than just importing a whole module (the C header-file mess). Maybe the proposed system could support both -- modules and individual functions? - Edmond - > and to provide short names (we can import a function > and not have to keep on repeating a long long name for it). > > I note, without recommendation either way, > the existence of > > local > > in > > end > > in Standard ML, where the second lot of declarations > defines things visible outside but the first lot > defines things visible only inside this form. > >> fib(N) -> >> fib(N, 1, 0). >> >> fib(N, A, B) when N < 2 -> A; >> fib(N, A, B) -> fib(N-1, A+B, A). > > could be > > local > fun fib_aux n a b = if n < 2 then a else fib_aux (n-1) (a+b) a > in > fun fib n = fib_aux n 1 0 > end > > in SML. I also note that this is NOT something that SML uses instead > of modules. > >> Does the idea of a module come from the idea that functions have to be >> >> stored somewhere, so we store them in a file, and we slurp the >> file (as a unit) into the system, so the file becomes a module? > > Probably not. Smalltalk has classes, but the unit of compilation is a > single method, and the unit of storage is classically a "change set" > (which may involve any number of classes and methods, and may include > revisions to existing classes). > > I also note that in the days when Interlisp-D was just that and did > not include Xerox Common Lisp, you slurped a file (as a unit) into the > system, but there were no modules. > > There are plenty of languages where a file may contain many modules, > possibly nested. (SML, Ada, to name just two.) > >> If all the files were store by themselves in a database would this >> change things. >> >> I am thinking more and more that if would be nice to have *all* >> functions in >> a key_value database with unique names. > > In Erlang as it stands, a source file is the natural unit of version > control and documentation. The idea of coping with a sea of functions > all being busily revised by hundreds if not thousands of programmers > acting asynchronously troubles me. > > Haskell has a large package library, and people can update things often, > and I keep on seeing version issues in the Haskell-caf? mailing list. > > Can > - scope of names > - grain of compilation and reloading > - version control > - documentation > - units of (program) storage > be teased apart? > > Smalltalk seems to suggest that something along these lines might be > doable. (Smalltalk methods are version controlled individually.) > However, Smalltalk documentation, especially internal documentation, > varies between woeful and dire. > > >> When programs are large we need a lot of meta-data to understand them. > > The Xerox slogan: a program is a data base, not a listing. > Interlisp-D did not strictly speaking _have_ source files. > There were files with source code in them, but they were > randomly accessed data bases. Thanks to macros, this did > not work as well as one might hope, but it did work after > a fashion. > > Hey, maybe this could be a way to get rid of the preprocessor! > > Joe, you've invented one great language, this is crazy enough to > be the concept for a second one. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From bengt.kleberg@REDACTED Wed May 25 08:16:28 2011 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Wed, 25 May 2011 08:16:28 +0200 Subject: [erlang-questions] Unidirectional linking? In-Reply-To: References: Message-ID: <1306304188.5874.8.camel@seasc1137> Greetings, Uni-directional links are created with erlang:monitor/2. Does this help? bengt On Wed, 2011-05-25 at 08:00 +0200, Igor Ribeiro Sucupira wrote: > Suppose there is a heavy operation Op that in some cases takes so long > to finish that the caller loses interest in the result and gives up. > > I want to perform that operation in a way that allows me to: > 1) Interrupt its execution if it does not finish in N milliseconds. > 2) Interrupt its execution if the calling process exits (here I'm > already supposing Op has to be run in another Erlang process, due to > goal 1). > > To implement that, it seems unidirectional linking would be needed. Is > there another safe and convenient way to do it? > > The first idea I had was something like this: > > Parent = self(), > Child = spawn_link(fun() -> Parent ! (catch Op) end), > receive Result -> Result > after N -> unlink(Child), exit(Child, timeout), timeout > end. > > But, if Parent is killed by another process right after calling > unlink, Child would be left executing. > Another problem is that I don't want Parent to die if Child exits for > non-timeout reasons (although it seems very unlikely in the code > above, with the catch). > > I was now thinking of substituting unlink(Child) with > process_flag(trap_exit, true) and then kill Child, receive its exit > message, set trap_exit to false again (I'm assuming it was false), and > finally check if there were other exit messages (suiciding if it was > the case). > > But then the code would become too ugly, so I got lazy and decided to > post to this list. :-) > > What do you think? > > Thanks. > Igor. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From jeffm@REDACTED Wed May 25 08:16:48 2011 From: jeffm@REDACTED (jm) Date: Wed, 25 May 2011 16:16:48 +1000 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: <4DDC9ED0.9090900@ghostgun.com> On 25/05/11 2:51 PM, Richard O'Keefe wrote: > > Back in the early days of the language Pop, the people at > the Edinburgh AI department had a game. The whole machine > they were using was programmed in Pop, on top of bare metal. > The game goes like this: > how much of the system can you zap before you have > to reboot the machine? > > How much of a shared sea-of-functions can you update before > having to revert to backups? > This is an aside, but one of those things I've been wondering about. Is there a language in existence which scales from "here's a piece of bare metal" and scales up to declarative distributed programming of the likes of Erlang? At the moment, it seems that the accepted way is to change from assembler to C to something else. Is there a language that progresses from the low level machine code basics up by adding language features and improving the runtime environment which is written in itself, ie turtles all the way down, and is more than an AST written in ascii (I'm looking at you lisp)? Jeff. From ok@REDACTED Wed May 25 08:18:19 2011 From: ok@REDACTED (Richard O'Keefe) Date: Wed, 25 May 2011 18:18:19 +1200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: <43D550AC-1CA3-4AD9-983F-88B035B6DD36@cs.otago.ac.nz> On 24/05/2011, at 10:26 PM, Jesper Louis Andersen wrote: > On Tue, May 24, 2011 at 10:06, Joe Armstrong wrote: >> Why do we need modules at all? > > I think we need modules, but this post sparked a thought I have had > for some time now. > > I'd like to have module renaming/namespacing! This has been proposed in some detail. Can't remember who by, but I think his initials were R.A.O'K. (:-) That proposal was inspired by Eiffel's LACE configuration language. From mazen.harake@REDACTED Wed May 25 08:20:40 2011 From: mazen.harake@REDACTED (Mazen Harake) Date: Wed, 25 May 2011 08:20:40 +0200 Subject: [erlang-questions] Unidirectional linking? In-Reply-To: References: Message-ID: Why would someone "kill the parent"? Do you have processes which are randomly choosing other processes to terminate? ;) If your answer is "No" then I would suggest that you just kill the worker processes that is taking to long, kill it in cold blood, imo. There is no reason to think about too many "if"-scenarios when the scenarios are too far fetched. Try the simple version first :) otherwise you can either trap_exits or use monitors instead. /M On 25 May 2011 08:00, Igor Ribeiro Sucupira wrote: > Suppose there is a heavy operation Op that in some cases takes so long > to finish that the caller loses interest in the result and gives up. > > I want to perform that operation in a way that allows me to: > 1) Interrupt its execution if it does not finish in N milliseconds. > 2) Interrupt its execution if the calling process exits (here I'm > already supposing Op has to be run in another Erlang process, due to > goal 1). > > To implement that, it seems unidirectional linking would be needed. Is > there another safe and convenient way to do it? > > The first idea I had was something like this: > > Parent = self(), > Child = spawn_link(fun() -> Parent ! (catch Op) end), > receive Result -> Result > after N -> unlink(Child), exit(Child, timeout), timeout > end. > > But, if Parent is killed by another process right after calling > unlink, Child would be left executing. > Another problem is that I don't want Parent to die if Child exits for > non-timeout reasons (although it seems very unlikely in the code > above, with the catch). > > I was now thinking of substituting unlink(Child) with > process_flag(trap_exit, true) and then kill Child, receive its exit > message, set trap_exit to false again (I'm assuming it was false), and > finally check if there were other exit messages (suiciding if it was > the case). > > But then the code would become too ugly, so I got lazy and decided to > post to this list. :-) > > What do you think? > > Thanks. > Igor. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From igorrs@REDACTED Wed May 25 08:24:23 2011 From: igorrs@REDACTED (Igor Ribeiro Sucupira) Date: Wed, 25 May 2011 03:24:23 -0300 Subject: [erlang-questions] Unidirectional linking? In-Reply-To: <1306304188.5874.8.camel@seasc1137> References: <1306304188.5874.8.camel@seasc1137> Message-ID: I couldn't see a way of using monitors in this example. I would need the child process to monitor its parent, but the child is busy performing Op. Thanks. Igor. On Wed, May 25, 2011 at 3:16 AM, Bengt Kleberg wrote: > Greetings, > > Uni-directional links are created with erlang:monitor/2. > > Does this help? > > > bengt > > On Wed, 2011-05-25 at 08:00 +0200, Igor Ribeiro Sucupira wrote: >> Suppose there is a heavy operation Op that in some cases takes so long >> to finish that the caller loses interest in the result and gives up. >> >> I want to perform that operation in a way that allows me to: >> 1) Interrupt its execution if it does not finish in N milliseconds. >> 2) Interrupt its execution if the calling process exits (here I'm >> already supposing Op has to be run in another Erlang process, due to >> goal 1). >> >> To implement that, it seems unidirectional linking would be needed. Is >> there another safe and convenient way to do it? >> >> The first idea I had was something like this: >> >> Parent = self(), >> Child = spawn_link(fun() -> Parent ! (catch Op) end), >> receive Result -> Result >> after N -> unlink(Child), exit(Child, timeout), timeout >> end. >> >> But, if Parent is killed by another process right after calling >> unlink, Child would be left executing. >> Another problem is that I don't want Parent to die if Child exits for >> non-timeout reasons (although it seems very unlikely in the code >> above, with the catch). >> >> I was now thinking of substituting unlink(Child) with >> process_flag(trap_exit, true) and then kill Child, receive its exit >> message, set trap_exit to false again (I'm assuming it was false), and >> finally check if there were other exit messages (suiciding if it was >> the case). >> >> But then the code would become too ugly, so I got lazy and decided to >> post to this list. ?:-) >> >> What do you think? >> >> Thanks. >> Igor. >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From ok@REDACTED Wed May 25 08:33:12 2011 From: ok@REDACTED (Richard O'Keefe) Date: Wed, 25 May 2011 18:33:12 +1200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: <4D538FB5-C347-4133-8111-721F3C2B42F0@cs.otago.ac.nz> On 25/05/2011, at 12:45 AM, Joe Armstrong wrote: > > > On Tue, May 24, 2011 at 1:56 PM, Max Lapshin wrote: > Very strange topic for me. > > I'd like to know if there will be hierarchial modules in Erlang, > because tree of packages is a rather good idea: > > No it's not - this has been the subject of long and heated discussion and is > why packages are NOT in Erlang - many people - myself included - dislike > the idea of hierarchical namespaces. The *dot* in the name has no semantics > it's just a separator. The name could equally well be encoders.mpg.erlyvideo > or mpg.applications.erlvideo.encoder - there is no logical way to organise the > package name and it does not scale - I should point out that Haskell has dotted names, uses them to indicate semantics, and has a *managed* hierarchical name space; Data.* and Control.* and Net.* and so on are tolerably clear. I should also admit that there are occasional complaints about it not being clear where things have been put, and other indexing and searching tools are often used to find things. From norton@REDACTED Wed May 25 08:34:34 2011 From: norton@REDACTED (Joseph Wayne Norton) Date: Wed, 25 May 2011 15:34:34 +0900 Subject: [erlang-questions] Unidirectional linking? In-Reply-To: References: <1306304188.5874.8.camel@seasc1137> Message-ID: Igor - I suggest to add a simple proxy process (or add this functionality to the parent process if it is better suited) that has a receive clause for the operation's response, the operation's monitor exit, and an after clause with the operation's timeout. If timeout occurs, you can demonitor and kill the operation's process. - Joe N On Wed, 25 May 2011 15:24:23 +0900, Igor Ribeiro Sucupira wrote: > I couldn't see a way of using monitors in this example. I would need > the child process to monitor its parent, but the child is busy > performing Op. > > Thanks. > Igor. > > On Wed, May 25, 2011 at 3:16 AM, Bengt Kleberg > wrote: >> Greetings, >> >> Uni-directional links are created with erlang:monitor/2. >> >> Does this help? >> >> >> bengt >> >> On Wed, 2011-05-25 at 08:00 +0200, Igor Ribeiro Sucupira wrote: >>> Suppose there is a heavy operation Op that in some cases takes so long >>> to finish that the caller loses interest in the result and gives up. >>> >>> I want to perform that operation in a way that allows me to: >>> 1) Interrupt its execution if it does not finish in N milliseconds. >>> 2) Interrupt its execution if the calling process exits (here I'm >>> already supposing Op has to be run in another Erlang process, due to >>> goal 1). >>> >>> To implement that, it seems unidirectional linking would be needed. Is >>> there another safe and convenient way to do it? >>> >>> The first idea I had was something like this: >>> >>> Parent = self(), >>> Child = spawn_link(fun() -> Parent ! (catch Op) end), >>> receive Result -> Result >>> after N -> unlink(Child), exit(Child, timeout), timeout >>> end. >>> >>> But, if Parent is killed by another process right after calling >>> unlink, Child would be left executing. >>> Another problem is that I don't want Parent to die if Child exits for >>> non-timeout reasons (although it seems very unlikely in the code >>> above, with the catch). >>> >>> I was now thinking of substituting unlink(Child) with >>> process_flag(trap_exit, true) and then kill Child, receive its exit >>> message, set trap_exit to false again (I'm assuming it was false), and >>> finally check if there were other exit messages (suiciding if it was >>> the case). >>> >>> But then the code would become too ugly, so I got lazy and decided to >>> post to this list. :-) >>> >>> What do you think? >>> >>> Thanks. >>> Igor. >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- norton@REDACTED From igorrs@REDACTED Wed May 25 08:39:07 2011 From: igorrs@REDACTED (Igor Ribeiro Sucupira) Date: Wed, 25 May 2011 03:39:07 -0300 Subject: [erlang-questions] Unidirectional linking? In-Reply-To: References: <1306304188.5874.8.camel@seasc1137> Message-ID: I was thinking about something like that right now, trying to convince myself that it could work with a third process. :) Thanks! I will try it. Best regards. Igor. -- "The secret of joy in work is contained in one word - excellence. To know how to do something well is to enjoy it." - Pearl S. Buck. On Wed, May 25, 2011 at 3:34 AM, Joseph Wayne Norton wrote: > > Igor - > > I suggest to add a simple proxy process (or add this functionality to the > parent process if it is better suited) that has a receive clause for the > operation's response, the operation's monitor exit, and an after clause with > the operation's timeout. ?If timeout occurs, you can demonitor and kill the > operation's process. > > - Joe N > > On Wed, 25 May 2011 15:24:23 +0900, Igor Ribeiro Sucupira > wrote: > >> I couldn't see a way of using monitors in this example. I would need >> the child process to monitor its parent, but the child is busy >> performing Op. >> >> Thanks. >> Igor. >> >> On Wed, May 25, 2011 at 3:16 AM, Bengt Kleberg >> wrote: >>> >>> Greetings, >>> >>> Uni-directional links are created with erlang:monitor/2. >>> >>> Does this help? >>> >>> >>> bengt >>> >>> On Wed, 2011-05-25 at 08:00 +0200, Igor Ribeiro Sucupira wrote: >>>> >>>> Suppose there is a heavy operation Op that in some cases takes so long >>>> to finish that the caller loses interest in the result and gives up. >>>> >>>> I want to perform that operation in a way that allows me to: >>>> 1) Interrupt its execution if it does not finish in N milliseconds. >>>> 2) Interrupt its execution if the calling process exits (here I'm >>>> already supposing Op has to be run in another Erlang process, due to >>>> goal 1). >>>> >>>> To implement that, it seems unidirectional linking would be needed. Is >>>> there another safe and convenient way to do it? >>>> >>>> The first idea I had was something like this: >>>> >>>> Parent = self(), >>>> Child = spawn_link(fun() -> Parent ! (catch Op) end), >>>> receive Result -> Result >>>> after N -> unlink(Child), exit(Child, timeout), timeout >>>> end. >>>> >>>> But, if Parent is killed by another process right after calling >>>> unlink, Child would be left executing. >>>> Another problem is that I don't want Parent to die if Child exits for >>>> non-timeout reasons (although it seems very unlikely in the code >>>> above, with the catch). >>>> >>>> I was now thinking of substituting unlink(Child) with >>>> process_flag(trap_exit, true) and then kill Child, receive its exit >>>> message, set trap_exit to false again (I'm assuming it was false), and >>>> finally check if there were other exit messages (suiciding if it was >>>> the case). >>>> >>>> But then the code would become too ugly, so I got lazy and decided to >>>> post to this list. ?:-) >>>> >>>> What do you think? >>>> >>>> Thanks. >>>> Igor. >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > > -- > norton@REDACTED From ok@REDACTED Wed May 25 08:45:22 2011 From: ok@REDACTED (Richard O'Keefe) Date: Wed, 25 May 2011 18:45:22 +1200 Subject: [erlang-questions] System timers, now/0, and instrumentation In-Reply-To: References: <673380092.213661306227737701.JavaMail.root@zimbra> Message-ID: <7C243B92-39B6-4DB3-9D65-4E7538AD7B57@cs.otago.ac.nz> On 25/05/2011, at 7:09 AM, Jack Moffitt wrote: >> The question is whether they are readily available. Sub-ms resolution timers >> appear to be 'an exercise for the reader' for Windows developers, rather >> than an OS-provided tool. > > QueryPerformanceCounter() is pretty readily available as far as I > remember. Here's something Google brought up for implementing > microsecond timers with it: > http://www.decompile.com/cpp/faq/windows_timer_api.htm Er, there's a problem with the performance counters, isn't there? now() is supposed to give you a clock, something that ticks regularly. The performance counters count events in the CPU, and today's power-sensitive CPUs do things like scaling back the CPU clock frequency when they think they aren't busy. I know people keep telling me that time monitoring using cpu cycle counters doesn't work any more; I can't say of my own knowledge whether they are right. From igorrs@REDACTED Wed May 25 08:51:27 2011 From: igorrs@REDACTED (Igor Ribeiro Sucupira) Date: Wed, 25 May 2011 03:51:27 -0300 Subject: [erlang-questions] Unidirectional linking? In-Reply-To: References: Message-ID: Supposing someone used the same logic (with timeout/kill) to spawn the parent process, the parent could be killed at any moment (but yeah: it would be bad luck to have that happening right after it called unlink). Thanks. Igor. On Wed, May 25, 2011 at 3:20 AM, Mazen Harake wrote: > Why would someone "kill the parent"? Do you have processes which are > randomly choosing other processes to terminate? ;) > > If your answer is "No" then I would suggest that you just kill the worker > processes that is taking to long, kill it in cold blood, imo. > > There is no reason to think about too many "if"-scenarios when the scenarios > are too far fetched. Try the simple version first :) > > otherwise you can either trap_exits or use monitors instead. > > /M > > On 25 May 2011 08:00, Igor Ribeiro Sucupira wrote: >> >> Suppose there is a heavy operation Op that in some cases takes so long >> to finish that the caller loses interest in the result and gives up. >> >> I want to perform that operation in a way that allows me to: >> 1) Interrupt its execution if it does not finish in N milliseconds. >> 2) Interrupt its execution if the calling process exits (here I'm >> already supposing Op has to be run in another Erlang process, due to >> goal 1). >> >> To implement that, it seems unidirectional linking would be needed. Is >> there another safe and convenient way to do it? >> >> The first idea I had was something like this: >> >> Parent = self(), >> Child = spawn_link(fun() -> Parent ! (catch Op) end), >> receive Result -> Result >> after N -> unlink(Child), exit(Child, timeout), timeout >> end. >> >> But, if Parent is killed by another process right after calling >> unlink, Child would be left executing. >> Another problem is that I don't want Parent to die if Child exits for >> non-timeout reasons (although it seems very unlikely in the code >> above, with the catch). >> >> I was now thinking of substituting unlink(Child) with >> process_flag(trap_exit, true) and then kill Child, receive its exit >> message, set trap_exit to false again (I'm assuming it was false), and >> finally check if there were other exit messages (suiciding if it was >> the case). >> >> But then the code would become too ugly, so I got lazy and decided to >> post to this list. ?:-) >> >> What do you think? >> >> Thanks. >> Igor. >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > From ok@REDACTED Wed May 25 09:07:04 2011 From: ok@REDACTED (Richard O'Keefe) Date: Wed, 25 May 2011 19:07:04 +1200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: <0C2A2F3C-C259-425A-A15A-B3D71D9EA4AD@cs.otago.ac.nz> On 25/05/2011, at 3:34 PM, Edmond Begumisa wrote: > Hello Joe, > > I've personally wanted an easy way to load modules from different places. > > If you started with making modules easy to load from different places, then later provide support for functions, I imagine this would be easier to implement immediately and easier for people to make use of immediately ... where "people" refers to me :) > > I've got two suggestions (mostly inspired by the Mozilla Framework)... > > 1. How about letting the programmer choose where the functions come from (kv store, fs, web-server, etc)... > > For instance, a module could start... > > -import(["file://misc/collect_int", "http://erlang.org/lists/*", "mnesia://db1/misc/merge_kv"]). Why does this have to be done inside the module? Why cannot the mapping from module names to sources be *outside*, like an SGML (or XML) catalogue, or a .lace file? From bengt.kleberg@REDACTED Wed May 25 09:11:48 2011 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Wed, 25 May 2011 09:11:48 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: <0C2A2F3C-C259-425A-A15A-B3D71D9EA4AD@cs.otago.ac.nz> References: <0C2A2F3C-C259-425A-A15A-B3D71D9EA4AD@cs.otago.ac.nz> Message-ID: <1306307508.5874.24.camel@seasc1137> Moreover, to solve the problem this should work for two different beam modules, having the same name, being used at the same time. Since they are already compiled we must do the mapping outside of the modules. bengt On Wed, 2011-05-25 at 09:07 +0200, Richard O'Keefe wrote: > On 25/05/2011, at 3:34 PM, Edmond Begumisa wrote: > > > Hello Joe, > > > > I've personally wanted an easy way to load modules from different places. > > > > If you started with making modules easy to load from different places, then later provide support for functions, I imagine this would be easier to implement immediately and easier for people to make use of immediately ... where "people" refers to me :) > > > > I've got two suggestions (mostly inspired by the Mozilla Framework)... > > > > 1. How about letting the programmer choose where the functions come from (kv store, fs, web-server, etc)... > > > > For instance, a module could start... > > > > -import(["file://misc/collect_int", "http://erlang.org/lists/*", "mnesia://db1/misc/merge_kv"]). > > Why does this have to be done inside the module? > Why cannot the mapping from module names to sources > be *outside*, like an SGML (or XML) catalogue, > or a .lace file? > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From igorrs@REDACTED Wed May 25 09:13:55 2011 From: igorrs@REDACTED (Igor Ribeiro Sucupira) Date: Wed, 25 May 2011 04:13:55 -0300 Subject: [erlang-questions] Unidirectional linking? In-Reply-To: References: <1306304188.5874.8.camel@seasc1137> Message-ID: The Parent might call this right before calling unlink: spawn(fun() -> erlang:monitor(Parent), erlang:monitor(Child), receive {'DOWN', _, _, _, _} -> erlang:exit(Child, timeout) end end), This way, if Parent dies right after calling unlink, the monitor process will kill Child and then exit. If the Parent succeeds in unlinking and then killing Child, the monitor will be notified of the death of Child and will also finish. Not perfect, not beautiful, but maybe it is enough. Thanks. Igor. On Wed, May 25, 2011 at 3:39 AM, Igor Ribeiro Sucupira wrote: > I was thinking about something like that right now, trying to convince > myself that it could work with a third process. :) ?Thanks! I will try > it. > > Best regards. > Igor. > > -- > "The secret of joy in work is contained in one word - excellence. To > know how to do something well is to enjoy it." - Pearl S. Buck. > > > On Wed, May 25, 2011 at 3:34 AM, Joseph Wayne Norton > wrote: >> >> Igor - >> >> I suggest to add a simple proxy process (or add this functionality to the >> parent process if it is better suited) that has a receive clause for the >> operation's response, the operation's monitor exit, and an after clause with >> the operation's timeout. ?If timeout occurs, you can demonitor and kill the >> operation's process. >> >> - Joe N >> >> On Wed, 25 May 2011 15:24:23 +0900, Igor Ribeiro Sucupira >> wrote: >> >>> I couldn't see a way of using monitors in this example. I would need >>> the child process to monitor its parent, but the child is busy >>> performing Op. >>> >>> Thanks. >>> Igor. >>> >>> On Wed, May 25, 2011 at 3:16 AM, Bengt Kleberg >>> wrote: >>>> >>>> Greetings, >>>> >>>> Uni-directional links are created with erlang:monitor/2. >>>> >>>> Does this help? >>>> >>>> >>>> bengt >>>> >>>> On Wed, 2011-05-25 at 08:00 +0200, Igor Ribeiro Sucupira wrote: >>>>> >>>>> Suppose there is a heavy operation Op that in some cases takes so long >>>>> to finish that the caller loses interest in the result and gives up. >>>>> >>>>> I want to perform that operation in a way that allows me to: >>>>> 1) Interrupt its execution if it does not finish in N milliseconds. >>>>> 2) Interrupt its execution if the calling process exits (here I'm >>>>> already supposing Op has to be run in another Erlang process, due to >>>>> goal 1). >>>>> >>>>> To implement that, it seems unidirectional linking would be needed. Is >>>>> there another safe and convenient way to do it? >>>>> >>>>> The first idea I had was something like this: >>>>> >>>>> Parent = self(), >>>>> Child = spawn_link(fun() -> Parent ! (catch Op) end), >>>>> receive Result -> Result >>>>> after N -> unlink(Child), exit(Child, timeout), timeout >>>>> end. >>>>> >>>>> But, if Parent is killed by another process right after calling >>>>> unlink, Child would be left executing. >>>>> Another problem is that I don't want Parent to die if Child exits for >>>>> non-timeout reasons (although it seems very unlikely in the code >>>>> above, with the catch). >>>>> >>>>> I was now thinking of substituting unlink(Child) with >>>>> process_flag(trap_exit, true) and then kill Child, receive its exit >>>>> message, set trap_exit to false again (I'm assuming it was false), and >>>>> finally check if there were other exit messages (suiciding if it was >>>>> the case). >>>>> >>>>> But then the code would become too ugly, so I got lazy and decided to >>>>> post to this list. ?:-) >>>>> >>>>> What do you think? >>>>> >>>>> Thanks. >>>>> Igor. >>>>> _______________________________________________ >>>>> erlang-questions mailing list >>>>> erlang-questions@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> -- >> norton@REDACTED > From ebegumisa@REDACTED Wed May 25 09:18:09 2011 From: ebegumisa@REDACTED (Edmond Begumisa) Date: Wed, 25 May 2011 17:18:09 +1000 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: <0C2A2F3C-C259-425A-A15A-B3D71D9EA4AD@cs.otago.ac.nz> References: <0C2A2F3C-C259-425A-A15A-B3D71D9EA4AD@cs.otago.ac.nz> Message-ID: That's precisely what I was suggesting in suggestion 2... > ... 2. Expanding on this: letting the programmer centralise the possible > locations ... That "erlang.manfest" contains is a prop_list that maps "erlang://" URIs to actual locations. Sorry it wasn't clear enough. - Edmond - On Wed, 25 May 2011 17:07:04 +1000, Richard O'Keefe wrote: > > On 25/05/2011, at 3:34 PM, Edmond Begumisa wrote: > >> Hello Joe, >> >> I've personally wanted an easy way to load modules from different >> places. >> >> If you started with making modules easy to load from different places, >> then later provide support for functions, I imagine this would be >> easier to implement immediately and easier for people to make use of >> immediately ... where "people" refers to me :) >> >> I've got two suggestions (mostly inspired by the Mozilla Framework)... >> >> 1. How about letting the programmer choose where the functions come >> from (kv store, fs, web-server, etc)... >> >> For instance, a module could start... >> >> -import(["file://misc/collect_int", "http://erlang.org/lists/*", >> "mnesia://db1/misc/merge_kv"]). > > Why does this have to be done inside the module? > Why cannot the mapping from module names to sources > be *outside*, like an SGML (or XML) catalogue, > or a .lace file? > > -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From mjtruog@REDACTED Wed May 25 09:25:48 2011 From: mjtruog@REDACTED (Michael Truog) Date: Wed, 25 May 2011 00:25:48 -0700 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: <4D538FB5-C347-4133-8111-721F3C2B42F0@cs.otago.ac.nz> References: <4D538FB5-C347-4133-8111-721F3C2B42F0@cs.otago.ac.nz> Message-ID: <4DDCAEFC.20604@gmail.com> On 05/24/2011 11:33 PM, Richard O'Keefe wrote: > On 25/05/2011, at 12:45 AM, Joe Armstrong wrote: >> >> On Tue, May 24, 2011 at 1:56 PM, Max Lapshin wrote: >> Very strange topic for me. >> >> I'd like to know if there will be hierarchial modules in Erlang, >> because tree of packages is a rather good idea: >> >> No it's not - this has been the subject of long and heated discussion and is >> why packages are NOT in Erlang - many people - myself included - dislike >> the idea of hierarchical namespaces. The *dot* in the name has no semantics >> it's just a separator. The name could equally well be encoders.mpg.erlyvideo >> or mpg.applications.erlvideo.encoder - there is no logical way to organise the >> package name and it does not scale - > I should point out that Haskell has dotted names, > uses them to indicate semantics, > and has a *managed* hierarchical name space; > Data.* and Control.* and Net.* and so on are > tolerably clear. > > I should also admit that there are occasional complaints > about it not being clear where things have been put, and > other indexing and searching tools are often used to find > things. Anthropologists supposedly think that wanting a taxonomy is very natural (http://en.wikipedia.org/wiki/Taxonomy#Taxonomy_and_mental_classification). A hierarchy may not be formed in a way that everyone would expect because we lack a collective mind. However, I think that source code requires organization to be manageable. To make a hierarchy flexible, pointers could be used to represent different interpretations of what the hierarchy could be. If a large collaborative effort was formed to generate source code, it is important that code is reused to reduce complexity. A hierarchy would be our most natural way of determining source code that can be referenced to build larger systems, and that would make the dependency more likely to receive maintenance. That would helps us avoid the current situation with things like jungerl. I don't think it is important whether we use a '.' character or a '_' character to create a hierarchy with the names in our source code. However, the '.' character used by the undocumented Erlang package functionality could be used to provide better support for unmanageable hierarchies, perhaps with search and documentation benefits. The other part to imposing order on a large collaborative effort seems to be determining the quality of the code for reuse. A rating system could be used and doesn't require a hierarchy. However, with many different common segments of source code available, a hierarchy can provide a way of focusing on relevant source code and should promote code reuse. From mazen.harake@REDACTED Wed May 25 09:28:31 2011 From: mazen.harake@REDACTED (Mazen Harake) Date: Wed, 25 May 2011 09:28:31 +0200 Subject: [erlang-questions] Unidirectional linking? In-Reply-To: References: Message-ID: Perhaps something like this: process_flag(trap_exit, true), Parent = self(), Child = spawn_link(fun() -> Parent ! (catch Op) end), receive {'EXIT', ParentsParent, Reason} -> exit(Reason); Result -> Result after N -> unlink(Child), exit(Child, timeout), timeout end. if you get an exit signal from the parent's parent you will exit if you are in the receive clause and you will ignore it (unless it is a kill) if you are in between the unlink and exit child? I do however still think that this is very defensive and that the probability of getting an exit between unlink and exit is very small unless the timeout in N is exactly the same (very very close to) the timeout that the parent's parent has for exiting the parent. On 25 May 2011 08:51, Igor Ribeiro Sucupira wrote: > Supposing someone used the same logic (with timeout/kill) to spawn the > parent process, the parent could be killed at any moment (but yeah: it > would be bad luck to have that happening right after it called > unlink). > > Thanks. > Igor. > > On Wed, May 25, 2011 at 3:20 AM, Mazen Harake > wrote: > > Why would someone "kill the parent"? Do you have processes which are > > randomly choosing other processes to terminate? ;) > > > > If your answer is "No" then I would suggest that you just kill the worker > > processes that is taking to long, kill it in cold blood, imo. > > > > There is no reason to think about too many "if"-scenarios when the > scenarios > > are too far fetched. Try the simple version first :) > > > > otherwise you can either trap_exits or use monitors instead. > > > > /M > > > > On 25 May 2011 08:00, Igor Ribeiro Sucupira wrote: > >> > >> Suppose there is a heavy operation Op that in some cases takes so long > >> to finish that the caller loses interest in the result and gives up. > >> > >> I want to perform that operation in a way that allows me to: > >> 1) Interrupt its execution if it does not finish in N milliseconds. > >> 2) Interrupt its execution if the calling process exits (here I'm > >> already supposing Op has to be run in another Erlang process, due to > >> goal 1). > >> > >> To implement that, it seems unidirectional linking would be needed. Is > >> there another safe and convenient way to do it? > >> > >> The first idea I had was something like this: > >> > >> Parent = self(), > >> Child = spawn_link(fun() -> Parent ! (catch Op) end), > >> receive Result -> Result > >> after N -> unlink(Child), exit(Child, timeout), timeout > >> end. > >> > >> But, if Parent is killed by another process right after calling > >> unlink, Child would be left executing. > >> Another problem is that I don't want Parent to die if Child exits for > >> non-timeout reasons (although it seems very unlikely in the code > >> above, with the catch). > >> > >> I was now thinking of substituting unlink(Child) with > >> process_flag(trap_exit, true) and then kill Child, receive its exit > >> message, set trap_exit to false again (I'm assuming it was false), and > >> finally check if there were other exit messages (suiciding if it was > >> the case). > >> > >> But then the code would become too ugly, so I got lazy and decided to > >> post to this list. :-) > >> > >> What do you think? > >> > >> Thanks. > >> Igor. > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questions@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-questions > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebegumisa@REDACTED Wed May 25 09:28:51 2011 From: ebegumisa@REDACTED (Edmond Begumisa) Date: Wed, 25 May 2011 17:28:51 +1000 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: <1306307508.5874.24.camel@seasc1137> References: <0C2A2F3C-C259-425A-A15A-B3D71D9EA4AD@cs.otago.ac.nz> <1306307508.5874.24.camel@seasc1137> Message-ID: On Wed, 25 May 2011 17:11:48 +1000, Bengt Kleberg wrote: > Moreover, to solve the problem this should work for two different beam > modules, having the same name, being used at the same time. Since they > are already compiled we must do the mapping outside of the modules. > > > bengt > Yes, in my second suggestion the mappings would be outside the modules, in a single "manifest" file. This idea comes from the way "chrome.manifest" and the "chrome://" URI works in Mozilla (those who've written Firefox/Thunderbird extensions would be familiar with it.) The code loader would have to consult the manifest file for the "real" locations of the modules. That's what I was trying to describe here... > 2. Expanding on this: letting the programmer centralise the possible > locations of modules/functions and use this to define namespaces... > > One possible way of doing this is to steal from the "chrome > registration" system that the Mozilla Framework uses. A programmer could > define one-level deep namespaces in a configuration file which points to > targets that could come from anywhere, then use that in her modules. A > module could then start... > > -import(["erlang://misc/collect_int", "erlang://couch/mapreduce"]). > > Where "misc" and "couch" are namespaces and "erlang://" is a special URI > scheme telling the code loader to refer to the configuration file > "erlang.manifest" which would contain... > > [{"misc", "file://./ebin/misc.beam"}, > {"couch", "http://localhost:7777/ebin/"}] > > Where "couch" points to a yaws server serving couch beams, or something > along those lines. Then she can easy switch between different code > sources using one file. > > A code-signing system could also be introduced. > - Edmond - > On Wed, 2011-05-25 at 09:07 +0200, Richard O'Keefe wrote: >> On 25/05/2011, at 3:34 PM, Edmond Begumisa wrote: >> >> > Hello Joe, >> > >> > I've personally wanted an easy way to load modules from different >> places. >> > >> > If you started with making modules easy to load from different >> places, then later provide support for functions, I imagine this would >> be easier to implement immediately and easier for people to make use of >> immediately ... where "people" refers to me :) >> > >> > I've got two suggestions (mostly inspired by the Mozilla Framework)... >> > >> > 1. How about letting the programmer choose where the functions come >> from (kv store, fs, web-server, etc)... >> > >> > For instance, a module could start... >> > >> > -import(["file://misc/collect_int", "http://erlang.org/lists/*", >> "mnesia://db1/misc/merge_kv"]). >> >> Why does this have to be done inside the module? >> Why cannot the mapping from module names to sources >> be *outside*, like an SGML (or XML) catalogue, >> or a .lace file? >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From ok@REDACTED Wed May 25 09:30:44 2011 From: ok@REDACTED (Richard O'Keefe) Date: Wed, 25 May 2011 19:30:44 +1200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: <4DDC9ED0.9090900@ghostgun.com> References: <4DDC9ED0.9090900@ghostgun.com> Message-ID: <614E64ED-5E5B-40B9-AFF5-463C247087D3@cs.otago.ac.nz> On 25/05/2011, at 6:16 PM, jm wrote: > > Is there a language in existence which scales from "here's a piece of bare metal" and scales up to declarative distributed programming of the likes of Erlang? At the moment, it seems that the accepted way is to change from assembler to C to something else. Is there a language that progresses from the low level machine code basics up by adding language features and improving the runtime environment which is written in itself, ie turtles all the way down, and is more than an AST written in ascii (I'm looking at you lisp)? The original Smalltalk ran on bare metal. There is or was a "SqueakNOS" (no operating system) port that ran on bare metal, but with a glue layer in C. Interlisp-D ran on bare metal. There were some low level primitives, but you quickly got into Lisp, and everything from the garbage collector to the network and file system stacks as in Lisp. Lisp machines ditto. In both the MIT and Xerox lisp machines, you could twiddle bits in registers or work on natural language translation. Lisp is definitely more than an AST written in ASCII, and there are several Algol-ish front ends for it. Reduce has (had?) RLisp and Macsyma used CGOL, I think. The Poplog system ran under VMS, and because they were serving lots of undergraduates, they really wanted a rock solid time sharing system underneath. But there's a language layer called Syspop that gets you quite low, with Pop11, Prolog, Common Lisp, and ML layered on top. My experience with Interlisp-D was that you really want to hide the bottom level pretty quickly. From adiaz@REDACTED Wed May 25 09:45:51 2011 From: adiaz@REDACTED (Amancio =?ISO-8859-1?Q?D=EDaz_Su=E1rez?=) Date: Wed, 25 May 2011 09:45:51 +0200 Subject: [erlang-questions] esmtp: send PDF as an attachment In-Reply-To: References: <22D4C8B4-9E83-4380-A9A9-06D0E871107F@gmail.com> <1306255968.27369.156.camel@cag0001w798> Message-ID: <1306309551.27369.237.camel@cag0001w798> Hi, El mi?, 25-05-2011 a las 00:23 +0200, Antoine Koener escribi?: > Some thoughts: > > On May 24, 2011, at 18:52 , Amancio D?az Su?rez wrote: > > > {ok, PngContent0} = file:read_file(?MAIL_PNG_LOGO), > > PngContent1 = base64:encode(PngContent0), > > PngContent = erlang:binary_to_list(PngContent1), > > Are you sure that you need to build a List ? > In the example PngContent1 is a binary, if I use it directly I got a badarg: Error calling [ EmailPdf ] Reason [ error ] Error [ badarg ] BackTrace [ [{erlang,'++',[<<105,86....67,67>>,[13,10]]}, {esmtp_mime,encode_part,2}, {lists,map,2}, {lists,map,2}, {esmtp_mime,encode,1}, {esmtp,send,1}.... Building a list it works fine. Amancio. From octopusfluff@REDACTED Wed May 25 10:20:12 2011 From: octopusfluff@REDACTED (Amy Lear) Date: Wed, 25 May 2011 01:20:12 -0700 Subject: [erlang-questions] System timers, now/0, and instrumentation In-Reply-To: <7C243B92-39B6-4DB3-9D65-4E7538AD7B57@cs.otago.ac.nz> References: <673380092.213661306227737701.JavaMail.root@zimbra> <7C243B92-39B6-4DB3-9D65-4E7538AD7B57@cs.otago.ac.nz> Message-ID: On Tue, May 24, 2011 at 11:45 PM, Richard O'Keefe wrote: > > On 25/05/2011, at 7:09 AM, Jack Moffitt wrote: > > QueryPerformanceCounter() is pretty readily available as far as I > > remember. Here's something Google brought up for implementing > > microsecond timers with it: > > http://www.decompile.com/cpp/faq/windows_timer_api.htm > > Er, there's a problem with the performance counters, isn't there? > now() is supposed to give you a clock, something that ticks > regularly. > The performance counters count events in the CPU, and today's > power-sensitive CPUs do things like scaling back the CPU clock > frequency when they think they aren't busy. > > I know people keep telling me that time monitoring using cpu > cycle counters doesn't work any more; I can't say of my own knowledge > whether they are right. > According to msdn, QueryPerformanceCounter() is the solution to problems like RDTSC slipping in power management ( http://msdn.microsoft.com/en-us/library/ee417693%28v=vs.85%29.aspx circa 2005), but some later discussions ( http://www.red-gate.com/supportcenter/Content?p=ANTS%20Performance%20Profiler&c=ANTS_Performance_Profiler\knowledgebase\app_speedstep.htm) suggest that newer power management techniques (such as AMD cool'n'quiet) could defeat the efforts of that timer to maintain a steady beat. It's hard to tell if that has been addressed by Microsoft or not since then. I'm really at a loss as to what the right solution here could be. I have trouble imagining there isn't one, but I'm not well-versed enough in the architecture to know where else to look. I do know that right now there is a higher resolution timer available than what now/0 uses, but I'm not clear on what the performance penalty of os:timestamp/0 is in comparison, and I wouldn't know how to properly measure it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Wed May 25 10:37:39 2011 From: erlang@REDACTED (Joe Armstrong) Date: Wed, 25 May 2011 10:37:39 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: <9ED39284-56EE-4FA3-9985-C806339BEAB4@dev-extend.eu> Message-ID: On Wed, May 25, 2011 at 7:46 AM, Tim Watson wrote: > > Unfortunately information about individual functions is > > scattered all over the place. I want the source, the type signature, > > the documentation. These are available in a variety of different > > formats in different places. Documentation is in untagged comments > > in @tagged edoc format or in XML in a completely different file. > > Yes, this is a really important part of it. Being able to slurp in > Erlang projects from the file system (and github, etc), access all > this information and provide it in a searchable fashion would > *already* put us way ahead of the crowd in terms of discovery. > > > Silly design question: if multiple people can edit (say) a wiki > > of functions what formatting standards should be enforced? > > > > - the last person who edited the text > > - some "moderator" (who) > > - by a pretty printer > > (is there a *really good* pp? - with color syntax marking) > > I think there are reasonable ones around. Take a look at > http://tidier.softlab.ntua.gr:20000/tidier/getstarted. I would also > propose that you let the viewer configure the pp to their own > preferences. Given that you're actually storing abstract code (or AST > or something like that) rather than lines of source code anyway, this > is just human readable representation after all. Let people view with > whatever (potentially hideous) whitespace &c convention they like. > Very interesting idea - there was once a pascal pretty printer that analysed your code and inferred the style that you preferred - "Umm this guy likes semi-colons at the end of line ..." they in applied it to code you hadn't written. > > >> I'm guessing this will require patching the compiler to preserve the > >> type specs in the beam code. That is something I would need help with, > >> but may be trivial for others. > > > > Easy - it is there already (I think) poke around in beam_lib.erl > > this analyses the .beam files. > > > > I was pretty sure this wasn't the case. I'll dig in to beam_lib at > lunch time and have another look. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Wed May 25 10:40:46 2011 From: erlang@REDACTED (Joe Armstrong) Date: Wed, 25 May 2011 10:40:46 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: <20110525055849.GD22828@aluminum.local> References: <9ED39284-56EE-4FA3-9985-C806339BEAB4@dev-extend.eu> <20110525055849.GD22828@aluminum.local> Message-ID: On Wed, May 25, 2011 at 7:58 AM, Vance Shipley wrote: > Joe, > > I love the idea of ditching modules files and storing functions > in a data store. What I'm picturing though is that the functions > are stored in their abstract syntax form (i.e. data) so that the > issue of formatting standards is stripped away. You need tools > which translate it in and out so that we can continue to use the > editors we are familiar with but you can edit in emacs using it's > bizarre indentation and I can use vim and indent with tabs. ROK > can put seperators at the begging of lines, I'll see them at the > end. > > I have long wanted to put a toolchain together which allowed me > to easily store abstract syntax in the source code control system > repository. The check in and check out processes would convert > (pretty print) it to my personal prefernce settings. > > YES > The problem with that plan seems to be with the preprocessor. It > seems to me though that your plan suffers the same problem. If > macros are defined at a module level, or in an include file, you'll > have to deal with them when you pull the functions out of the module > and stuff it into the data store. The extended syntax tree used in > the erl_syntax application might be the answer. > YES > > How do you deal with record definitions? > > YES :-) - compile their hash into the function? > -- > -Vance > > On Tue, May 24, 2011 at 10:08:40PM +0200, Joe Armstrong wrote: > } Silly design question: if multiple people can edit (say) a wiki > } of functions what formatting standards should be enforced? > } > } - the last person who edited the text > } - some "moderator" (who) > } - by a pretty printer > } (is there a *really good* pp? - with color syntax marking) > > -- > -Vance > -------------- next part -------------- An HTML attachment was scrubbed... URL: From igorrs@REDACTED Wed May 25 10:50:40 2011 From: igorrs@REDACTED (Igor Ribeiro Sucupira) Date: Wed, 25 May 2011 05:50:40 -0300 Subject: [erlang-questions] Unidirectional linking? In-Reply-To: References: Message-ID: Parent will probably need to do more work after it gets the result from Child, so, in the end, you would need to restore trap_exit to false (unless it wasn't false before) and then call receive again, to make sure there weren't other exit messages while trap_exit was true. That's what worries me about the trap_exit solution: the more code you need, the more conditions you may be forgetting to consider. I am planning to put that logic inside of a "general" function (something like catch_apply(Module, Function, Args, Timeout)) and use it in my system (that handles hundreds of requests per second). It may happen, for example, that Op1 calls OpA and OpB, while Op2 calls OpC and OpA, with Op1 and Op2 having different timeouts. So, it may get very wild and, having some experience with that kind of load, I have seen in practice that race conditions are very real. In the first use case I'm planning, leaking Child or having Parent dying (or not dying) by mistake sometimes might not be so bad. But one day other people may begin to use the function for other operations and I don't want anybody hurt. :) Thanks! Igor. -- "The secret of joy in work is contained in one word - excellence. To know how to do something well is to enjoy it." - Pearl S. Buck. On Wed, May 25, 2011 at 4:28 AM, Mazen Harake wrote: > Perhaps something like this: > > process_flag(trap_exit, true), > Parent = self(), > Child = spawn_link(fun() -> Parent ! (catch Op) end), > receive > ? {'EXIT', ParentsParent, Reason} -> > ??? exit(Reason); > ? Result -> > ??? Result > ?after N -> > ??? unlink(Child), > ??? exit(Child, timeout), > ??? timeout > end. > > if you get an exit signal from the parent's parent you will exit if you are > in the receive clause and you will ignore it (unless it is a kill) if you > are in between the unlink and exit child? > > I do however still think that this is very defensive and that the > probability of getting an exit between unlink and exit is very small unless > the timeout in N is exactly the same (very very close to) the timeout that > the parent's parent has for exiting the parent. > > > > On 25 May 2011 08:51, Igor Ribeiro Sucupira wrote: >> >> Supposing someone used the same logic (with timeout/kill) to spawn the >> parent process, the parent could be killed at any moment (but yeah: it >> would be bad luck to have that happening right after it called >> unlink). >> >> Thanks. >> Igor. >> >> On Wed, May 25, 2011 at 3:20 AM, Mazen Harake >> wrote: >> > Why would someone "kill the parent"? Do you have processes which are >> > randomly choosing other processes to terminate? ;) >> > >> > If your answer is "No" then I would suggest that you just kill the >> > worker >> > processes that is taking to long, kill it in cold blood, imo. >> > >> > There is no reason to think about too many "if"-scenarios when the >> > scenarios >> > are too far fetched. Try the simple version first :) >> > >> > otherwise you can either trap_exits or use monitors instead. >> > >> > /M >> > >> > On 25 May 2011 08:00, Igor Ribeiro Sucupira wrote: >> >> >> >> Suppose there is a heavy operation Op that in some cases takes so long >> >> to finish that the caller loses interest in the result and gives up. >> >> >> >> I want to perform that operation in a way that allows me to: >> >> 1) Interrupt its execution if it does not finish in N milliseconds. >> >> 2) Interrupt its execution if the calling process exits (here I'm >> >> already supposing Op has to be run in another Erlang process, due to >> >> goal 1). >> >> >> >> To implement that, it seems unidirectional linking would be needed. Is >> >> there another safe and convenient way to do it? >> >> >> >> The first idea I had was something like this: >> >> >> >> Parent = self(), >> >> Child = spawn_link(fun() -> Parent ! (catch Op) end), >> >> receive Result -> Result >> >> after N -> unlink(Child), exit(Child, timeout), timeout >> >> end. >> >> >> >> But, if Parent is killed by another process right after calling >> >> unlink, Child would be left executing. >> >> Another problem is that I don't want Parent to die if Child exits for >> >> non-timeout reasons (although it seems very unlikely in the code >> >> above, with the catch). >> >> >> >> I was now thinking of substituting unlink(Child) with >> >> process_flag(trap_exit, true) and then kill Child, receive its exit >> >> message, set trap_exit to false again (I'm assuming it was false), and >> >> finally check if there were other exit messages (suiciding if it was >> >> the case). >> >> >> >> But then the code would become too ugly, so I got lazy and decided to >> >> post to this list. ?:-) >> >> >> >> What do you think? >> >> >> >> Thanks. >> >> Igor. >> >> _______________________________________________ >> >> erlang-questions mailing list >> >> erlang-questions@REDACTED >> >> http://erlang.org/mailman/listinfo/erlang-questions >> > >> > > > From robert.virding@REDACTED Wed May 25 10:54:43 2011 From: robert.virding@REDACTED (Robert Virding) Date: Wed, 25 May 2011 08:54:43 +0000 (GMT) Subject: [erlang-questions] Erlang Factory London (June 9th&10th) - Early Bird Deadline Today In-Reply-To: Message-ID: <471644119.218511306313683925.JavaMail.root@zimbra> ----- "Joe Armstrong" wrote: > > > > On Tue, May 24, 2011 at 9:30 PM, Francesco Cesarini < francesco@REDACTED > wrote: > Hi All, > > a note to remind you that tonight is the early bird deadline for the Erlang Factory in London June 9th and 10th. With over 50 speakers, 40 talks, 6 tracks and 5 courses, this is going to be the largest Erlang feast in Europe, equal only to the conference we ran in the US this March: > > http://www.erlang-factory.com/conference/London2011/programme/34 > > We have speakers from companies such as Basho, Ericsson, AOL, Yahoo!, WMware, Heroku and Erlang Solutions. Speakers include Erlang co-inventors Mike Williams and Robert Virding, Matthew Sackman, who worked on the first RabbitMQ prototype, Tony Falco and Scott Lystig Fritche on Riak, Kresten Krab of Erjang fame, Ulf Wiger and Adam Lindberg from ESL, Bob Ippolito, creator of Mochi Web, and Steve Vinoski, yaws and distributed systems guru. I could go on, as everyone deserves a mention, but you are better off having a look at the speaker list yourselves. Themes this year are Erlang in databases, embedded, Erlang in gaming, and test driven development. Lots of it! And for the first time, we are introducing a Business Track which looks at the advantages of Erlang from a social and economical point of view (read non-technical). All (well, almost. We are chasing the last abstracts) of the talks are listed here: > > http://www.erlang-factory.com/conference/London2011/talks > > At 12am Samoa Local Time, the early bird rate giving you a savings of 100 GBP on the full price will finish. As of today, we have more registered delegates than last year. There are also a few places at the University, with 4 3-day training courses prior to the conference, but not many. So if you are considering attending, register asap: > > https://www.erlang-factory.com/conference/London2011/register > > Rumors have it Joe will be there (reuniting the three original inventors), and that Mike will be wearing a tie. > > Hello Mike > Hello Robert > Hello Joe Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebegumisa@REDACTED Wed May 25 10:54:43 2011 From: ebegumisa@REDACTED (Edmond Begumisa) Date: Wed, 25 May 2011 18:54:43 +1000 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: Motivation: If I can easily load modules or Joe's functions from different locations, then I can deploy my Erlang applications similarly to web-applications. I'm using Erlang at both the client and the server. Currently, reltool and appup I've found a too tedious. web-app style deployment would have big advantages... * In corporate environments: clients can have a bare-bones installation, launch that, then get most of the Erlang code from a central server. Upgrading everyone is replacing a few files on the server. I could write some simple code to upgrade modules already loaded by clients. * On the web: With code-signing supported, I can safely deploy all applications on my startup's web-server. I get all users (using different completely applications) to download and install the *same* single bare-bones installation. Erlang code for the different apps comes from my web-server. Users whose licenses run dry can't access newer code. - Edmond - On Wed, 25 May 2011 13:34:17 +1000, Edmond Begumisa wrote: > Hello Joe, > > I've personally wanted an easy way to load modules from different places. > > If you started with making modules easy to load from different places, > then later provide support for functions, I imagine this would be easier > to implement immediately and easier for people to make use of > immediately ... where "people" refers to me :) > > I've got two suggestions (mostly inspired by the Mozilla Framework)... > > 1. How about letting the programmer choose where the functions come from > (kv store, fs, web-server, etc)... > > For instance, a module could start... > > -import(["file://misc/collect_int", "http://erlang.org/lists/*", > "mnesia://db1/misc/merge_kv"]). > > By default, the code loader would know what to do when it encounters > "file://", "http://", "https://", "ftp://", "sftp://" and "mnesia://" > URI schemes. Programmers could be allowed define their own URI schemes > by providing callbacks for loading code. For instance, one would be able > to define "ubf://" and have the code loader call his/her code when it > encounters "ubf://foo/bar" > > 2. Expanding on this: letting the programmer centralise the possible > locations of modules/functions and use this to define namespaces... > > One possible way of doing this is to steal from the "chrome > registration" system that the Mozilla Framework uses. A programmer could > define one-level deep namespaces in a configuration file which points to > targets that could come from anywhere, then use that in her modules. A > module could then start... > > -import(["erlang://misc/collect_int", "erlang://couch/mapreduce"]). > > Where "misc" and "couch" are namespaces and "erlang://" is a special URI > scheme telling the code loader to refer to the configuration file > "erlang.manifest" which would contain... > > [{"misc", "file://./ebin/misc.beam"}, > {"couch", "http://localhost:7777/ebin/"}] > > Where "couch" points to a yaws server serving couch beams, or something > along those lines. Then she can easy switch between different code > sources using one file. > > A code-signing system could also be introduced. > > - Edmond - > > > On Tue, 24 May 2011 18:06:19 +1000, Joe Armstrong > wrote: > >> Why do we need modules at all? >> >> This is a brain-dump-stream-of-consciousness-thing. I've been >> thinking about this for a while. >> >> I'm proposing a slightly different way of programming here >> The basic idea is >> >> - do away with modules >> - all functions have unique distinct names >> - all functions have (lots of) meta data >> - all functions go into a global (searchable) Key-value database >> - we need letrec >> - contribution to open source can be as simple as >> contributing a single function >> - there are no "open source projects" - only "the open source >> Key-Value database of all functions" >> - Content is peer reviewed >> >> These are discussed in no particular order below: >> >> Why does Erlang have modules? >> >> There's a good an bad side to modules: >> >> Good: Provides a unit of compilation, a unit of code >> distribution. unit of code replacement >> >> Bad: It's very difficult to decide which module to put an individual >> function in. Break encapsulation (see later) >> >> Aside: lib_misc.erl >> >> When I'm programming I often get to the point were I say there should >> a function foo/2 in lists.erl but their isn't. There should be but >> there isn't - foo/2 is a small self contained thing. Why should it be >> in lists.erl because it "feels right". >> >> Strings are lists, so why do we have two modules lists.erl and >> string.erl how should I decide in which module my new string/list >> processing function should go. >> >> To avoid all mental anguish when I need a small function that >> should be somewhere else and isn't I stick it in >> a module elib1_misc.erl. >> >> My elib1_misc exports the following: >> >> added_files/2 make_challenge/0 >> as_bits/1 make_response/2 >> as_bits_test/0 make_response_test/0 >> bdump/2 make_test_strings/1 >> bin2hex/1 make_test_strings_test/0 >> bin2hex_test/0 make_tmp_filename/2 >> check_io_list/1 merge_kv/1 >> collect_atom/1 merge_kv_test/0 >> collect_atom_test/0 mini_shell/0 >> collect_int/1 module_info/0 >> collect_int_test/0 module_info/1 >> collect_string/1 ndots/1 >> collect_string_test/0 nibble_to_hex_char/1 >> collect_word/1 nibble_to_hex_char_test/0 >> complete/2 odd/1 >> complete_test/0 on_exit/2 >> dos2unix/1 out_of_date/2 >> downcase_char/1 outfile/2 >> dump/2 padd/2 >> dump_tmp/2 perms/1 >> duplicates/1 perms_test/0 >> ensure_started/2 pmap/2 >> eval_file/1 pmap1/2 >> eval_file_test/0 pmap1_test/0 >> eval_string/1 pmap_test/0 >> eval_string_test/0 priority_receive/0 >> every/3 random_seed/0 >> expand_env_vars/1 random_string/1 >> expand_file_template/3 random_string/2 >> expand_string_template/2 read_at_most_n_lines/2 >> expand_tabs/1 read_at_most_n_lines_test/0 >> expand_tabs_test/0 remove_duplicates/1 >> expand_template/2 remove_duplicates_test/0 >> extract_attribute/2 remove_leading_and_trailing_whitespace/1 >> extract_attribute_test/0 >> remove_leading_and_trailing_whitespace_test/0 >> extract_prefix/2 remove_leading_whitespace/1 >> fetch/2 remove_prefix/2 >> fetch_test/0 remove_prefix_test/0 >> file2lines/1 remove_trailing_whitespace/1 >> file2lines_test/0 replace/3 >> file2md5/1 root_dir/0 >> file2numberedlines/1 rpc/2 >> file2numberedlines_test/0 safe/1 >> file2paras/1 show_loaded/1 >> file2stream/1 signed_byte_to_hex_string/1 >> file2string/1 signed_byte_to_hex_string_test/0 >> file2template/1 skip_blanks/1 >> file2term/1 skip_blanks_test/0 >> file_size_and_type/1 skip_to_nl/1 >> find_src/1 skip_to_nl_test/0 >> first/1 sleep/1 >> flatten_io_list/1 spawn_monitor/3 >> flush_buffer/0 split_at_char/2 >> for/3 split_at_char_test/0 >> force/1 split_list/2 >> foreach_chunk_in_file/3 split_list_test/0 >> foreach_word_in_file/2 string2exprs/1 >> foreach_word_in_string/2 string2exprs_test/0 >> forever/0 string2html/1 >> get_erl_section/2 string2latex/1 >> get_line/1 string2lines/1 >> get_line/2 string2lines_test/0 >> have_common_prefix/1 string2stream/1 >> have_common_prefix_test/0 string2stream_test/0 >> hex2bin/1 string2template/1 >> hex2bin_test/0 string2template_test/0 >> hex2list/1 string2term/1 >> hex2list_test/0 string2term_test/0 >> hex_nibble2int/1 string2toks/1 >> hex_nibble2int_test/0 string2toks_test/0 >> id/1 sub_binary/3 >> include_dir/0 template2file/3 >> include_file/1 term2file/2 >> interleave/2 term2string/1 >> is_alphanum/1 test/0 >> is_blank_line/1 test1_test/0 >> is_prefix/2 test_function_over_substrings/2 >> is_prefix_test/0 tex2pdf/1 >> is_response_correct/3 time_fun/2 >> keep_alive/2 time_stamp/0 >> lines2para/1 to_lower/1 >> list2frequency_distribution/1 to_lower_test/0 >> list2frequency_distribution_tetrim/1 >> longest_common_prefix/1 trim_test/0 >> longest_common_prefix_test/0 unconsult/2 >> lookup/2 unsigned_byte_to_hex_string/1 >> lorem/1 unsigned_byte_to_hex_string_test/0 >> ls/1 which/1 >> which_added/1 >> >> Now I find this very convenient when I write a new small utility >> function >> I stick in in elib1_misc.erl - no mental anguish in choosing a module >> name is involved. >> >> The observation that I find this very-convenient is telling me something >> about modules - I like my elib1_misc it feels right. >> >> (aside - It seems many development projects have their own private >> lib_miscs ...) >> >> Which brings me to the point of my question. >> >> Do we need module's at all? Erlang programs are composed of lots of >> small >> functions, the only place where modules seem useful is to hide a letrec. >> >> The classic example is fibonacci. We want to expose fib/1 but hide the >> helper function fib/3. Using modules we say >> >> -module(math). >> -export([fib/1]). >> >> fib(N) -> >> fib(N, 1, 0). >> >> fib(N, A, B) when N < 2 -> A; >> fib(N, A, B) -> fib(N-1, A+B, A). >> >> The downside is we have had to *invent* one module name math - whose >> *only* >> purpose is to hide the definition of fib/3 which we don't want to be >> made >> callable. >> >> If we put a second function into the module math, then this second >> function >> could call fib/3 which breaks the encapsulation of fib/3. >> >> We could say: >> >> let fib = fun(N) -> fib(N, 1, 0) end >> in >> fib(N, A, B) when N < 2 -> A; >> fib(N, A, B) -> fib(N-1, A+B, A). >> end. >> >> I hardly dare suggest a syntax for this since I've been following >> another thread in this forum where syntax discussion seem to encourage >> much comment. >> >> ** Please do suggest alternative syntax's here - but do not comment on >> other peoples suggestions ... >> >> I would like to just talk about why we have modules. >> >> Another question: >> >> Does the idea of a module come from the idea that functions have to be >> stored somewhere, so we store them in a file, and we slurp the >> file (as a unit) into the system, so the file becomes a module? >> >> If all the files were store by themselves in a database would this >> change things. >> >> I am thinking more and more that if would be nice to have *all* >> functions in >> a key_value database with unique names. >> >> lookup(foo,2) would get the definition foo foo/2 from a database. >> >> The unique names bit is interesting - is this a good idea. Qualified >> names (ie names like xxx:foo/2) or (a.b.c.foo/2) sounds like a good >> idea but but when I'm programming I have to invent the xxx or the >> a.b.c which is very difficult. It also involves the "decision problem" >> if the namespaces xxx and a.b.c already exist I have to *choose* which >> to put my new function in. >> >> I think there might be a case for alises here joe:foo/2 could be used >> while developing "joe" would expand to a horrible random local string >> the >> real name being ab123aZwerasch123123_foo/2 but I would not be able to >> publish my code or make it available to a third_part before I had >> chosen a sensible name. >> >> (( managing namespaces seems really tricky, a lot of peoople seem >> to thing that the problem goes away by adding "." 's to the name >> but managing a namespace with namees like foo.bar.baz.z is just as >> complex >> as managing a namespace with names like foo_bar_baz_z or names like >> 0x3af312a78a3f1ae123 - the problem is that we have to go from a symbolic >> name like www.a.b to a reference like 123.45.23.12 - but how do we >> discover >> the initial name www.a.b? - there are two answers - a) we are given the >> name >> (ie we click on a link) - we do not know the name but we search fo it )) >> >> >> When programs are small we can live with "just the code" in "a few >> modules" the ratio of code to meta data is high. >> >> When programs are large we need a lot of meta-data to understand them. >> >> I would like to see all functions with all meta-data in a data base. >> >> I'd like to say: >> >> lookup(foo,2,Attribute) when Attribute = >> >> code|source|documentation|type signatures|revision >> history|authors|... >> >> The more I think about it the more I think program development should >> viewed as changing the state of a Key-Value database. >> >> So I imagine: >> >> 1) all functions have unique names >> 2) there are no modules >> 3) we discover the name of a function by searching metadata >> describing the function in a database >> 4) all public functions (think open source) are in the same >> database >> >> We could make a system to do this. >> >> I think this would make open-source projects easier, since the >> granularity of contribution goes down. You could contribute >> a single function - not an entire application. >> >> (( A problem with GUT style open source projects is there is >> not one database of functions, I often what one function from >> this project, another function from another project -- the >> granularity of reusable parts should be the individual function. >> >> functions are really easy to reuse >> modules are more difficult to reuse >> entire applications are very difficult to reuse >> (Unless there are isolated through a communication channel)) >> >> Possible extensions. >> >> 1) Voting for promotion >> 2) A review process >> >> Given a raw database will *all* functions in it - we could derive an >> "approved" functions database. >> >> Popular functions could be moved to the approved database - the >> review process would need to be discussed - so kind of peer-review/wiki >> stuff. >> >> Comments? >> >> Volunteers? >> >> /Joe > > -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From vladdu55@REDACTED Wed May 25 10:55:21 2011 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Wed, 25 May 2011 10:55:21 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: <20110525055849.GD22828@aluminum.local> References: <9ED39284-56EE-4FA3-9985-C806339BEAB4@dev-extend.eu> <20110525055849.GD22828@aluminum.local> Message-ID: On Wed, May 25, 2011 at 07:58, Vance Shipley wrote: > I love the idea of ditching modules files and storing functions > in a data store. What I'm picturing though is that the functions > are stored in their abstract syntax form (i.e. data) so that the > issue of formatting standards is stripped away. > > The problem with that plan seems to be with the preprocessor. It > seems to me though that your plan suffers the same problem. If > macros are defined at a module level, or in an include file, you'll > have to deal with them when you pull the functions out of the module > and stuff it into the data store. The extended syntax tree used in > the erl_syntax application might be the answer. > There are more things that need to be preserved by the parser, which make existing pretty-printers less than good. For example: - integer values can be shown using different bases, from case to case, so one can't use a generic setting. So the parser needs to keep track of that. - comments have to be anchored somewhere in the code. erl_syntax guesses only almost right. Of course, if there is going to be a more advanced metadata mechanism, the comments belong there too. Also, I didn't understand where/how are record and macro definitions going to be stored and identified. As somebody else said it too, the best solution would be to get rid of them altogether and it's starting to look more and more like a different language :-) regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Wed May 25 10:55:53 2011 From: erlang@REDACTED (Joe Armstrong) Date: Wed, 25 May 2011 10:55:53 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: <4DDC5446.8030800@ghostgun.com> References: <4AA969E9-93F7-4E0F-8C36-E784D83F3F18@trifork.com> <4DDC5446.8030800@ghostgun.com> Message-ID: On Wed, May 25, 2011 at 2:58 AM, jm wrote: > On 24/05/11 9:25 PM, Joe Armstrong wrote: > >> >> If we think of modules as containers of functions, then a module is a "set >> of functions" - >> my problem is with granularity. The smallest unit of reuse is the module. >> Suppose my application >> want just one function from a particular module - I'm forced to load the >> entire module. >> >> This hampers reuse - I *often* read library code and find a single >> function and cut-and-paste it into >> my new code. It also discourages sharing - since the smallest unit I can >> share is a module. >> >> The unit of distribution is an application - a set of modules - why this >> could not be a list of functions >> I do not know. >> >> I think I'd like to view an application as something that offered a >> message based service that internally >> was constructed from a set of functions rather than a set of modules. >> >> > Here's a "mad hatter" suggestion. Introduce the concept of a "shadow" > module. For example, say your using the list module and your after a > lists:randomise/1. In this proposal you'd have your own lists module, say > joes_lists, > > -module(joes_lists) > > randomise(List) -> > %% code to randomise the order of the list > > > In you code you would then say, > > -shadows(joes_lists, lists). > > then use lists:randomise(AList) in your code. The compiler would first > check the lists module and if the required function didn't exist it would > use your modules. This would avoid you accidentially overriding the main > modules definitions which may cause confusion. In such a case, the clash > should be treated as a compilation error. > > The second part would be distribution and release management. There's > several ways this could be done one would be to have a script which would > build a set of "patch modules" which would be the cut down versions of your > own development modules containing only the code and associated > documentation your using in the current project. > > This is not mad hatter :-) Knuth mad a patch system years ago. You start off with a file - freeze it so it's read only then write patches (replace lines N1,N2 with ...) - he did this with no tool support. One problems today is how we work. We make file1 and edit it to file2, of course we can compute a patch P that transforms file1 to file2. P works like this: P = diff(file1, file2) such that patch(file, P) => file2 The problem with P is that is bears no meaningful semantic information - there is no intentionality. many years ago I thought we shuld have thingks like this: -module(foo). -export([bar/2], ...). ... This defines foo.erl (as usual) Now we define a patch bar.patch -patch(bar). -insert(foo). -insert(baz). -delete(foo:bar/2). -delete(baz:foo/4). -rename(baz:zxy/2, new/2). code as before ... A preprocessor takes bar.patch and makes bar.erl from the patch instructions. This defines a compile time editing operation - insert actually inserts code from foo.erl, delete deletes code ... There are just actually simple refactoring commands. The *nice* thing about bar.patch is we can preserves intentionality (if there is such a word) - the patches produced by diff are usless - this is why a revision control system want you to comment every diff. Here the place for comments is in the patch file. The above is really trivial to implement it would be relatively easy to generate a list of such commands from my (proposed) folding editor -insert(foo, "http://.....") would be very nice /Joe > Actually, it might be better to include this as part of the project > development: execute a script which scans your code repository and the > -shadow/2 compiler directives and generates the shadow modules as needed. > This could mean that your custom modules could be kept in a git or mercurial > repository, on a web server, or in a key-value store. The URLs would then be > part of the configuration for this script along with version tags, etc. Yes, > I going to ignore how the modules get in there in the first place. > > Jeff. > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Wed May 25 10:57:15 2011 From: erlang@REDACTED (Joe Armstrong) Date: Wed, 25 May 2011 10:57:15 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: On Wed, May 25, 2011 at 5:34 AM, Edmond Begumisa < ebegumisa@REDACTED> wrote: > Hello Joe, > > I've personally wanted an easy way to load modules from different places. > > If you started with making modules easy to load from different places, then > later provide support for functions, I imagine this would be easier to > implement immediately and easier for people to make use of immediately ... > where "people" refers to me :) > > I've got two suggestions (mostly inspired by the Mozilla Framework)... > > 1. How about letting the programmer choose where the functions come from > (kv store, fs, web-server, etc)... > > For instance, a module could start... > > -import(["file://misc/collect_int", "http://erlang.org/lists/*", > "mnesia://db1/misc/merge_kv"]). > > By default, the code loader would know what to do when it encounters > "file://", "http://", "https://", "ftp://", "sftp://" and "mnesia://" URI > schemes. Programmers could be allowed define their own URI schemes by > providing callbacks for loading code. For instance, one would be able to > define "ubf://" and have the code loader call his/her code when it > encounters "ubf://foo/bar" > > 2. Expanding on this: letting the programmer centralise the possible > locations of modules/functions and use this to define namespaces... > > One possible way of doing this is to steal from the "chrome registration" > system that the Mozilla Framework uses. A programmer could define one-level > deep namespaces in a configuration file which points to targets that could > come from anywhere, then use that in her modules. A module could then > start... > > -import(["erlang://misc/collect_int", "erlang://couch/mapreduce"]). > > Where "misc" and "couch" are namespaces and "erlang://" is a special URI > scheme telling the code loader to refer to the configuration file > "erlang.manifest" which would contain... > > [{"misc", "file://./ebin/misc.beam"}, > {"couch", "http://localhost:7777/ebin/"}] > > Where "couch" points to a yaws server serving couch beams, or something > along those lines. Then she can easy switch between different code sources > using one file. > > A code-signing system could also be introduced. > Did this a while back - you can also xform everything - all private modules can have their names changed to MD5SUM(Content) of the module IFYSWIM /Joe > > - Edmond - > > > > On Tue, 24 May 2011 18:06:19 +1000, Joe Armstrong > wrote: > > Why do we need modules at all? >> >> This is a brain-dump-stream-of-consciousness-thing. I've been >> thinking about this for a while. >> >> I'm proposing a slightly different way of programming here >> The basic idea is >> >> - do away with modules >> - all functions have unique distinct names >> - all functions have (lots of) meta data >> - all functions go into a global (searchable) Key-value database >> - we need letrec >> - contribution to open source can be as simple as >> contributing a single function >> - there are no "open source projects" - only "the open source >> Key-Value database of all functions" >> - Content is peer reviewed >> >> These are discussed in no particular order below: >> >> Why does Erlang have modules? >> >> There's a good an bad side to modules: >> >> Good: Provides a unit of compilation, a unit of code >> distribution. unit of code replacement >> >> Bad: It's very difficult to decide which module to put an individual >> function in. Break encapsulation (see later) >> >> Aside: lib_misc.erl >> >> When I'm programming I often get to the point were I say there should >> a function foo/2 in lists.erl but their isn't. There should be but >> there isn't - foo/2 is a small self contained thing. Why should it be >> in lists.erl because it "feels right". >> >> Strings are lists, so why do we have two modules lists.erl and >> string.erl how should I decide in which module my new string/list >> processing function should go. >> >> To avoid all mental anguish when I need a small function that >> should be somewhere else and isn't I stick it in >> a module elib1_misc.erl. >> >> My elib1_misc exports the following: >> >> added_files/2 make_challenge/0 >> as_bits/1 make_response/2 >> as_bits_test/0 make_response_test/0 >> bdump/2 make_test_strings/1 >> bin2hex/1 make_test_strings_test/0 >> bin2hex_test/0 make_tmp_filename/2 >> check_io_list/1 merge_kv/1 >> collect_atom/1 merge_kv_test/0 >> collect_atom_test/0 mini_shell/0 >> collect_int/1 module_info/0 >> collect_int_test/0 module_info/1 >> collect_string/1 ndots/1 >> collect_string_test/0 nibble_to_hex_char/1 >> collect_word/1 nibble_to_hex_char_test/0 >> complete/2 odd/1 >> complete_test/0 on_exit/2 >> dos2unix/1 out_of_date/2 >> downcase_char/1 outfile/2 >> dump/2 padd/2 >> dump_tmp/2 perms/1 >> duplicates/1 perms_test/0 >> ensure_started/2 pmap/2 >> eval_file/1 pmap1/2 >> eval_file_test/0 pmap1_test/0 >> eval_string/1 pmap_test/0 >> eval_string_test/0 priority_receive/0 >> every/3 random_seed/0 >> expand_env_vars/1 random_string/1 >> expand_file_template/3 random_string/2 >> expand_string_template/2 read_at_most_n_lines/2 >> expand_tabs/1 read_at_most_n_lines_test/0 >> expand_tabs_test/0 remove_duplicates/1 >> expand_template/2 remove_duplicates_test/0 >> extract_attribute/2 remove_leading_and_trailing_whitespace/1 >> extract_attribute_test/0 >> remove_leading_and_trailing_whitespace_test/0 >> extract_prefix/2 remove_leading_whitespace/1 >> fetch/2 remove_prefix/2 >> fetch_test/0 remove_prefix_test/0 >> file2lines/1 remove_trailing_whitespace/1 >> file2lines_test/0 replace/3 >> file2md5/1 root_dir/0 >> file2numberedlines/1 rpc/2 >> file2numberedlines_test/0 safe/1 >> file2paras/1 show_loaded/1 >> file2stream/1 signed_byte_to_hex_string/1 >> file2string/1 signed_byte_to_hex_string_test/0 >> file2template/1 skip_blanks/1 >> file2term/1 skip_blanks_test/0 >> file_size_and_type/1 skip_to_nl/1 >> find_src/1 skip_to_nl_test/0 >> first/1 sleep/1 >> flatten_io_list/1 spawn_monitor/3 >> flush_buffer/0 split_at_char/2 >> for/3 split_at_char_test/0 >> force/1 split_list/2 >> foreach_chunk_in_file/3 split_list_test/0 >> foreach_word_in_file/2 string2exprs/1 >> foreach_word_in_string/2 string2exprs_test/0 >> forever/0 string2html/1 >> get_erl_section/2 string2latex/1 >> get_line/1 string2lines/1 >> get_line/2 string2lines_test/0 >> have_common_prefix/1 string2stream/1 >> have_common_prefix_test/0 string2stream_test/0 >> hex2bin/1 string2template/1 >> hex2bin_test/0 string2template_test/0 >> hex2list/1 string2term/1 >> hex2list_test/0 string2term_test/0 >> hex_nibble2int/1 string2toks/1 >> hex_nibble2int_test/0 string2toks_test/0 >> id/1 sub_binary/3 >> include_dir/0 template2file/3 >> include_file/1 term2file/2 >> interleave/2 term2string/1 >> is_alphanum/1 test/0 >> is_blank_line/1 test1_test/0 >> is_prefix/2 test_function_over_substrings/2 >> is_prefix_test/0 tex2pdf/1 >> is_response_correct/3 time_fun/2 >> keep_alive/2 time_stamp/0 >> lines2para/1 to_lower/1 >> list2frequency_distribution/1 to_lower_test/0 >> list2frequency_distribution_tetrim/1 >> longest_common_prefix/1 trim_test/0 >> longest_common_prefix_test/0 unconsult/2 >> lookup/2 unsigned_byte_to_hex_string/1 >> lorem/1 unsigned_byte_to_hex_string_test/0 >> ls/1 which/1 >> which_added/1 >> >> Now I find this very convenient when I write a new small utility function >> I stick in in elib1_misc.erl - no mental anguish in choosing a module >> name is involved. >> >> The observation that I find this very-convenient is telling me something >> about modules - I like my elib1_misc it feels right. >> >> (aside - It seems many development projects have their own private >> lib_miscs ...) >> >> Which brings me to the point of my question. >> >> Do we need module's at all? Erlang programs are composed of lots of small >> functions, the only place where modules seem useful is to hide a letrec. >> >> The classic example is fibonacci. We want to expose fib/1 but hide the >> helper function fib/3. Using modules we say >> >> -module(math). >> -export([fib/1]). >> >> fib(N) -> >> fib(N, 1, 0). >> >> fib(N, A, B) when N < 2 -> A; >> fib(N, A, B) -> fib(N-1, A+B, A). >> >> The downside is we have had to *invent* one module name math - whose >> *only* >> purpose is to hide the definition of fib/3 which we don't want to be made >> callable. >> >> If we put a second function into the module math, then this second >> function >> could call fib/3 which breaks the encapsulation of fib/3. >> >> We could say: >> >> let fib = fun(N) -> fib(N, 1, 0) end >> in >> fib(N, A, B) when N < 2 -> A; >> fib(N, A, B) -> fib(N-1, A+B, A). >> end. >> >> I hardly dare suggest a syntax for this since I've been following >> another thread in this forum where syntax discussion seem to encourage >> much comment. >> >> ** Please do suggest alternative syntax's here - but do not comment on >> other peoples suggestions ... >> >> I would like to just talk about why we have modules. >> >> Another question: >> >> Does the idea of a module come from the idea that functions have to be >> stored somewhere, so we store them in a file, and we slurp the >> file (as a unit) into the system, so the file becomes a module? >> >> If all the files were store by themselves in a database would this >> change things. >> >> I am thinking more and more that if would be nice to have *all* functions >> in >> a key_value database with unique names. >> >> lookup(foo,2) would get the definition foo foo/2 from a database. >> >> The unique names bit is interesting - is this a good idea. Qualified >> names (ie names like xxx:foo/2) or (a.b.c.foo/2) sounds like a good >> idea but but when I'm programming I have to invent the xxx or the >> a.b.c which is very difficult. It also involves the "decision problem" >> if the namespaces xxx and a.b.c already exist I have to *choose* which >> to put my new function in. >> >> I think there might be a case for alises here joe:foo/2 could be used >> while developing "joe" would expand to a horrible random local string the >> real name being ab123aZwerasch123123_foo/2 but I would not be able to >> publish my code or make it available to a third_part before I had >> chosen a sensible name. >> >> (( managing namespaces seems really tricky, a lot of peoople seem >> to thing that the problem goes away by adding "." 's to the name >> but managing a namespace with namees like foo.bar.baz.z is just as complex >> as managing a namespace with names like foo_bar_baz_z or names like >> 0x3af312a78a3f1ae123 - the problem is that we have to go from a symbolic >> name like www.a.b to a reference like 123.45.23.12 - but how do we >> discover >> the initial name www.a.b? - there are two answers - a) we are given the >> name >> (ie we click on a link) - we do not know the name but we search fo it )) >> >> >> When programs are small we can live with "just the code" in "a few >> modules" the ratio of code to meta data is high. >> >> When programs are large we need a lot of meta-data to understand them. >> >> I would like to see all functions with all meta-data in a data base. >> >> I'd like to say: >> >> lookup(foo,2,Attribute) when Attribute = >> >> code|source|documentation|type signatures|revision >> history|authors|... >> >> The more I think about it the more I think program development should >> viewed as changing the state of a Key-Value database. >> >> So I imagine: >> >> 1) all functions have unique names >> 2) there are no modules >> 3) we discover the name of a function by searching metadata >> describing the function in a database >> 4) all public functions (think open source) are in the same >> database >> >> We could make a system to do this. >> >> I think this would make open-source projects easier, since the >> granularity of contribution goes down. You could contribute >> a single function - not an entire application. >> >> (( A problem with GUT style open source projects is there is >> not one database of functions, I often what one function from >> this project, another function from another project -- the >> granularity of reusable parts should be the individual function. >> >> functions are really easy to reuse >> modules are more difficult to reuse >> entire applications are very difficult to reuse >> (Unless there are isolated through a communication channel)) >> >> Possible extensions. >> >> 1) Voting for promotion >> 2) A review process >> >> Given a raw database will *all* functions in it - we could derive an >> "approved" functions database. >> >> Popular functions could be moved to the approved database - the >> review process would need to be discussed - so kind of peer-review/wiki >> stuff. >> >> Comments? >> >> Volunteers? >> >> /Joe >> > > > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Wed May 25 11:01:03 2011 From: erlang@REDACTED (Joe Armstrong) Date: Wed, 25 May 2011 11:01:03 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: <9ED39284-56EE-4FA3-9985-C806339BEAB4@dev-extend.eu> <20110525055849.GD22828@aluminum.local> Message-ID: On Wed, May 25, 2011 at 10:55 AM, Vlad Dumitrescu wrote: > On Wed, May 25, 2011 at 07:58, Vance Shipley wrote: > >> I love the idea of ditching modules files and storing functions >> in a data store. What I'm picturing though is that the functions >> are stored in their abstract syntax form (i.e. data) so that the >> issue of formatting standards is stripped away. > > >> >> >> The problem with that plan seems to be with the preprocessor. It >> seems to me though that your plan suffers the same problem. If >> macros are defined at a module level, or in an include file, you'll >> have to deal with them when you pull the functions out of the module >> and stuff it into the data store. The extended syntax tree used in >> the erl_syntax application might be the answer. >> > > There are more things that need to be preserved by the parser, which make > existing pretty-printers less than good. For example: > > - integer values can be shown using different bases, from case to case, so > one can't use a generic setting. So the parser needs to keep track of that. > The new parser/tokeniser does I'm not sure if its worked its way in the pretty printers - I do have some unpublished code that does exact colorization of the source program > - comments have to be anchored somewhere in the code. erl_syntax guesses > only almost right. Of course, if there is going to be a more advanced > metadata mechanism, the comments belong there too. > > Also, I didn't understand where/how are record and macro definitions going > to be stored and identified. As somebody else said it too, the best solution > would be to get rid of them altogether and it's starting to look more and > more like a different language :-) > > regards, > Vlad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimo+erlang-questions@REDACTED Wed May 25 11:07:30 2011 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Wed, 25 May 2011 11:07:30 +0200 Subject: [erlang-questions] System timers, now/0, and instrumentation In-Reply-To: References: <673380092.213661306227737701.JavaMail.root@zimbra> Message-ID: <20110525090730.GA6149@erix.ericsson.se> On Tue, May 24, 2011 at 02:32:47AM -0700, Amy Lear wrote: > On Tue, May 24, 2011 at 2:02 AM, Magnus Henoch < > magnus.henoch@REDACTED> wrote: > > > ----- "Amy Lear" wrote: > > > > > The issue here as I understand it is that the system clock itself > > > can't report things in the microsecond range (msdn states the > > > granularity is between 10ms and 15ms: > > > > > http://msdn.microsoft.com/en-us/library/system.datetimeoffset.utcnow.aspx > > > ), but the real values are being mangled to provide those guaranteed > > > unique values. Given that now/0 is the obvious means of doing > > > measurement for an erlang user -- and in fact the instrumentation > > > tools that ship with erlang also appear to rely on it -- this results > > > in puzzling and undesired behavior. > > > > Have you tried os:timestamp/0? It's like now/0 but without the > > uniqueness guarantee. I'm not sure what granularity it has on > > Windows, though. > > > > Hope this helps, > > > > Unfortunately, it appears that the granularity of os:timestamp/0 is no finer > than 1 ms, and the minimum resolution appears to be machine-dependant. Msdn > research also suggests that the 1ms resolution timer is slower to access > than the normal system clock, which could matter in some circumstances. > Conversely, dropping the uniqueness facet and being higher resolution than > now/0 does have some potential usefulness, but the erlang documentation > indicates that the provided profiling tools rely on now/0. The reason the provided profiling tools rely on now/0 is mostly that it has been around as long as they, plus the fact that now/0 never moves backwards, mostly moves forwards kind of sanely and is fairly lightweight makes it a nice but possibly somewhat inaccurate compromise for a generic profiling tool. > > My question about instrumentation stands: is there currently a way to do > high resolution profiling in Erlang on Windows? Is the requisite work of > setting up sub-ms resolution timers simply not done/too much work to > attempt? No. There is currenly nothing better built in than erlang:now/0 and os:timestamp/0. They could probably be improved on Windows but it was quite a while since we had anyone requiring (as in providing resources) us developing Erlang for Windows. Side note: timer:tc/2,3 is about / has been converted to use os:timestamp/0 instead. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From erlang@REDACTED Wed May 25 11:09:04 2011 From: erlang@REDACTED (Joe Armstrong) Date: Wed, 25 May 2011 11:09:04 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: <429CA039-E508-4918-91E7-9E2438BD5376@cs.otago.ac.nz> References: <429CA039-E508-4918-91E7-9E2438BD5376@cs.otago.ac.nz> Message-ID: On Wed, May 25, 2011 at 6:29 AM, Richard O'Keefe wrote: > On 24/05/2011, at 8:06 PM, Joe Armstrong wrote: > > > Why do we need modules at all? > > To hide data types, > and to provide short names (we can import a function > and not have to keep on repeating a long long name for it). > > I note, without recommendation either way, > the existence of > > local > > in > > end > > in Standard ML, where the second lot of declarations > defines things visible outside but the first lot > defines things visible only inside this form. > > > fib(N) -> > > fib(N, 1, 0). > > > > fib(N, A, B) when N < 2 -> A; > > fib(N, A, B) -> fib(N-1, A+B, A). > > could be > > local > fun fib_aux n a b = if n < 2 then a else fib_aux (n-1) (a+b) a > in > fun fib n = fib_aux n 1 0 > end > How about public Functions etc. private Functions etc. end. Functions etc is just a regular sequence of function defs macros, records etc. The use of the words public and private would attract hoards of programmers to our humble little language... /Joe > > in SML. I also note that this is NOT something that SML uses instead > of modules. > > >Does the idea of a module come from the idea that functions have to be > > > > stored somewhere, so we store them in a file, and we slurp the > > file (as a unit) into the system, so the file becomes a module? > > Probably not. Smalltalk has classes, but the unit of compilation is a > single method, and the unit of storage is classically a "change set" > (which may involve any number of classes and methods, and may include > revisions to existing classes). > > I also note that in the days when Interlisp-D was just that and did > not include Xerox Common Lisp, you slurped a file (as a unit) into the > system, but there were no modules. > > There are plenty of languages where a file may contain many modules, > possibly nested. (SML, Ada, to name just two.) > > > If all the files were store by themselves in a database would this > > change things. > > > > I am thinking more and more that if would be nice to have *all* functions > in > > a key_value database with unique names. > > In Erlang as it stands, a source file is the natural unit of version > control and documentation. The idea of coping with a sea of functions > all being busily revised by hundreds if not thousands of programmers > acting asynchronously troubles me. > > Haskell has a large package library, and people can update things often, > and I keep on seeing version issues in the Haskell-caf? mailing list. > > Can > - scope of names > - grain of compilation and reloading > - version control > - documentation > - units of (program) storage > be teased apart? > > Smalltalk seems to suggest that something along these lines might be > doable. (Smalltalk methods are version controlled individually.) > However, Smalltalk documentation, especially internal documentation, > varies between woeful and dire. > > > > When programs are large we need a lot of meta-data to understand them. > > The Xerox slogan: a program is a data base, not a listing. > Interlisp-D did not strictly speaking _have_ source files. > There were files with source code in them, but they were > randomly accessed data bases. Thanks to macros, this did > not work as well as one might hope, but it did work after > a fashion. > > Hey, maybe this could be a way to get rid of the preprocessor! > > Joe, you've invented one great language, this is crazy enough to > be the concept for a second one. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Wed May 25 11:15:44 2011 From: erlang@REDACTED (Joe Armstrong) Date: Wed, 25 May 2011 11:15:44 +0200 Subject: [erlang-questions] where is the best erlang pretty printer Message-ID: I need to identify the best possible erlang pretty printer. Are there several, or unpublished variants in existence? I want exact reproduction of inputted constants it $a should be pretty printed as $a and NOT 97. If anybody can send me some pointers I will download and test all the pretty printers and report back. /Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu55@REDACTED Wed May 25 11:19:34 2011 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Wed, 25 May 2011 11:19:34 +0200 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: <429CA039-E508-4918-91E7-9E2438BD5376@cs.otago.ac.nz> Message-ID: Hi, On Wed, May 25, 2011 at 11:09, Joe Armstrong wrote: > On Wed, May 25, 2011 at 6:29 AM, Richard O'Keefe wrote: > >> On 24/05/2011, at 8:06 PM, Joe Armstrong wrote: >> >> > Why do we need modules at all? >> >> To hide data types, >> and to provide short names (we can import a function >> and not have to keep on repeating a long long name for it). >> >> I note, without recommendation either way, >> the existence of >> local >> >> in >> >> end >> in Standard ML, where the second lot of declarations >> defines things visible outside but the first lot >> defines things visible only inside this form. >> >> How about > > public > Functions etc. > private > Functions etc. > end. > > Functions etc is just a regular sequence of function defs macros, records > etc. > Where would this declaration be located? This would in effect become a module definition, if I understand correctly? Will it point out functions from the "sea of functions" out there and group them together? What happens if some other such declaration says that my private functions are public? I think I need to think more about this. I would start by trying to describe a user that sits down and wants to write a program. What would he need to do? What support is needed from the tools? > The use of the words public and private would attract hoards of programmers > to our humble little > language... > :-) /Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From octopusfluff@REDACTED Wed May 25 11:21:40 2011 From: octopusfluff@REDACTED (Amy Lear) Date: Wed, 25 May 2011 02:21:40 -0700 Subject: [erlang-questions] System timers, now/0, and instrumentation In-Reply-To: <20110525090730.GA6149@erix.ericsson.se> References: <673380092.213661306227737701.JavaMail.root@zimbra> <20110525090730.GA6149@erix.ericsson.se> Message-ID: On Wed, May 25, 2011 at 2:07 AM, Raimo Niskanen wrote: > The reason the provided profiling tools rely on now/0 is mostly > that it has been around as long as they, plus the fact that > now/0 never moves backwards, mostly moves forwards kind > of sanely and is fairly lightweight makes it a nice but possibly > somewhat inaccurate compromise for a generic profiling tool. This makes sense. > No. There is currenly nothing better built in than erlang:now/0 and > os:timestamp/0. They could probably be improved on Windows but it > was quite a while since we had anyone requiring (as in providing > resources) us developing Erlang for Windows. > > Side note: timer:tc/2,3 is about / has been converted to use > os:timestamp/0 instead. Okay, good to know. I'm continuing to look into it from my end, and maybe I'll find something that could be usable to other people. Thanks for your time and attention. From watson.timothy@REDACTED Wed May 25 11:26:17 2011 From: watson.timothy@REDACTED (Tim Watson) Date: Wed, 25 May 2011 10:26:17 +0100 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: <9ED39284-56EE-4FA3-9985-C806339BEAB4@dev-extend.eu> Message-ID: > > Very interesting idea - there was once a pascal pretty printer that analysed > your code > and inferred the style that you preferred - "Umm this guy likes semi-colons > at the end of > line ..." they in applied it to code you hadn't written. >> >> I'm guessing this will require patching the compiler to preserve the >> >> type specs in the beam code. That is something I would need help with, >> >> but may be trivial for others. >> > >> > Easy - it is there already (I think) poke around in beam_lib.erl >> > this analyses the .beam files. >> > >> >> I was pretty sure this wasn't the case. I'll dig in to beam_lib at >> lunch time and have another look. > > So you're sort of correct. The specs are present in the abstract_code chunk. I'm guessing this will only be the case if (a) you've compiled with debug_info and/or (b) you've used the abstract_code parse_transform (from github?) to ensure it's present either way. You would need to make sure it is preserved in order to get the type info by inspecting the beam. Perhaps slurping dialyzers generated plt file(s) would be a better (more general) approach? Maybe we should talk to Kostis - I suspect the idea of a type-based search engine might whet his appetite somewhat. From vladdu55@REDACTED Wed May 25 11:29:17 2011 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Wed, 25 May 2011 11:29:17 +0200 Subject: [erlang-questions] where is the best erlang pretty printer In-Reply-To: References: Message-ID: Hi, On Wed, May 25, 2011 at 11:15, Joe Armstrong wrote: > I need to identify the best possible erlang pretty printer. > > Are there several, or unpublished variants in existence? > > I want exact reproduction of inputted constants > it $a should be pretty printed as $a and NOT 97. > Things like [$a, $b | "cde"] should be preserved, too. This is not only a pretty-printer problem. One can't take the existing abstract syntax tree and recreate the exact input, but special lexer and parser are needed that preserve the needed information. A problem with automatic formatting is also that there are situations where the rules one generally uses are resulting in an ugly layout and one has to make an exception or accept the ugliness. I know people that would never do the latter. /Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From kostis@REDACTED Wed May 25 11:29:43 2011 From: kostis@REDACTED (Kostis Sagonas) Date: Wed, 25 May 2011 12:29:43 +0300 Subject: [erlang-questions] where is the best erlang pretty printer In-Reply-To: References: Message-ID: <4DDCCC07.2020105@cs.ntua.gr> Joe Armstrong wrote: > I need to identify the best possible erlang pretty printer. > > Are there several, or unpublished variants in existence? > > I want exact reproduction of inputted constants > it $a should be pretty printed as $a and NOT 97. Can you be a bit more specific on your criteria for "best" ? Seems to that what you are asking for is not only ill-defined but pretty much (sic!) a subjective matter... Kostis From netch@REDACTED Wed May 25 11:35:50 2011 From: netch@REDACTED (Valentin Nechayev) Date: Wed, 25 May 2011 12:35:50 +0300 Subject: [erlang-questions] where is the best erlang pretty printer In-Reply-To: References: Message-ID: <20110525093550.GA84200@netch.kiev.ua> Wed, May 25, 2011 at 11:15:44, erlang wrote about "[erlang-questions] where is the best erlang pretty printer": > I need to identify the best possible erlang pretty printer. > > Are there several, or unpublished variants in existence? > > I want exact reproduction of inputted constants > it $a should be pretty printed as $a and NOT 97. > > If anybody can send me some pointers I will download > and test all the pretty printers and report back. Time to implement real strings? -netch- From raimo+erlang-questions@REDACTED Wed May 25 11:45:12 2011 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Wed, 25 May 2011 11:45:12 +0200 Subject: [erlang-questions] Unidirectional linking? In-Reply-To: References: Message-ID: <20110525094512.GB6149@erix.ericsson.se> On Wed, May 25, 2011 at 09:28:31AM +0200, Mazen Harake wrote: > Perhaps something like this: > > process_flag(trap_exit, true), > Parent = self(), > Child = spawn_link(fun() -> Parent ! (catch Op) end), > receive > {'EXIT', ParentsParent, Reason} -> > exit(Reason); > Result -> > Result > after N -> > unlink(Child), > exit(Child, timeout), > timeout > end. Can the parent always have trap_exit true? If so this becomes (rather) simple: process_flag(trap_exit, true), , , Parent = self(), Ref = make_ref(), Child = spawn_link(fun() -> Parent ! {Ref,Op()} end), receive {'EXIT',Child,Reason} -> receive {Ref,Result} -> {ok,Result} after 0 -> {error,Reason} end; after N -> exit(Child, timeout), receive {'EXIT',Child,timeout} -> receive {Ref,Result} -> {ok,Result} after 0 -> timeout end end end If you have no control over the parent trap_exit flag I see no other alternative than involving a third process. Note that when a linked process exits normally, the link causes no exit at the other end. You maybe should think about using supervisers and all the other heavy OTP stuff. It was designed for this kind of problems. > > if you get an exit signal from the parent's parent you will exit if you are > in the receive clause and you will ignore it (unless it is a kill) if you > are in between the unlink and exit child? > > I do however still think that this is very defensive and that the > probability of getting an exit between unlink and exit is very small unless > the timeout in N is exactly the same (very very close to) the timeout that > the parent's parent has for exiting the parent. > > > > On 25 May 2011 08:51, Igor Ribeiro Sucupira wrote: > > > Supposing someone used the same logic (with timeout/kill) to spawn the > > parent process, the parent could be killed at any moment (but yeah: it > > would be bad luck to have that happening right after it called > > unlink). > > > > Thanks. > > Igor. > > > > On Wed, May 25, 2011 at 3:20 AM, Mazen Harake > > wrote: > > > Why would someone "kill the parent"? Do you have processes which are > > > randomly choosing other processes to terminate? ;) > > > > > > If your answer is "No" then I would suggest that you just kill the worker > > > processes that is taking to long, kill it in cold blood, imo. > > > > > > There is no reason to think about too many "if"-scenarios when the > > scenarios > > > are too far fetched. Try the simple version first :) > > > > > > otherwise you can either trap_exits or use monitors instead. > > > > > > /M > > > > > > On 25 May 2011 08:00, Igor Ribeiro Sucupira wrote: > > >> > > >> Suppose there is a heavy operation Op that in some cases takes so long > > >> to finish that the caller loses interest in the result and gives up. > > >> > > >> I want to perform that operation in a way that allows me to: > > >> 1) Interrupt its execution if it does not finish in N milliseconds. > > >> 2) Interrupt its execution if the calling process exits (here I'm > > >> already supposing Op has to be run in another Erlang process, due to > > >> goal 1). > > >> > > >> To implement that, it seems unidirectional linking would be needed. Is > > >> there another safe and convenient way to do it? > > >> > > >> The first idea I had was something like this: > > >> > > >> Parent = self(), > > >> Child = spawn_link(fun() -> Parent ! (catch Op) end), > > >> receive Result -> Result > > >> after N -> unlink(Child), exit(Child, timeout), timeout > > >> end. > > >> > > >> But, if Parent is killed by another process right after calling > > >> unlink, Child would be left executing. > > >> Another problem is that I don't want Parent to die if Child exits for > > >> non-timeout reasons (although it seems very unlikely in the code > > >> above, with the catch). > > >> > > >> I was now thinking of substituting unlink(Child) with > > >> process_flag(trap_exit, true) and then kill Child, receive its exit > > >> message, set trap_exit to false again (I'm assuming it was false), and > > >> finally check if there were other exit messages (suiciding if it was > > >> the case). > > >> > > >> But then the code would become too ugly, so I got lazy and decided to > > >> post to this list. :-) > > >> > > >> What do you think? > > >> > > >> Thanks. > > >> Igor. > > >> _______________________________________________ > > >> erlang-questions mailing list > > >> erlang-questions@REDACTED > > >> http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From robert.virding@REDACTED Wed May 25 11:47:34 2011 From: robert.virding@REDACTED (Robert Virding) Date: Wed, 25 May 2011 09:47:34 +0000 (GMT) Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: <422189115.218971306316525202.JavaMail.root@zimbra> Message-ID: <1412828266.218991306316854442.JavaMail.root@zimbra> ----- "Anthony Ramine" wrote: > > Well then, forgive me for this little offtopic but you seem to know what is unapproved > and what is unfinished. Are structs - not your proper structs but the commented-out > production found in erl_parse.yrl struct -> atom tuple - an unapproved feature or an > unfinished feature? > It is the remains of an unfinished feature which no one ever removed. There are more commented out remains in erl_expand_records, erl_lint and erl_pp. They should really all be removed as if/when the new structs/frames are implemented they will be wrong and in the way. Robert From vances@REDACTED Wed May 25 12:21:17 2011 From: vances@REDACTED (Vance Shipley) Date: Wed, 25 May 2011 15:51:17 +0530 Subject: [erlang-questions] where is the best erlang pretty printer In-Reply-To: References: Message-ID: <20110525102116.GF22828@aluminum.local> On Wed, May 25, 2011 at 11:29:17AM +0200, Vlad Dumitrescu wrote: } A problem with automatic formatting is also that there are situations where } the rules one generally uses are resulting in an ugly layout and one has to } make an exception or accept the ugliness. I know people that would never do } the latter. After having done a good deal of coding using ASN.1 modules I found that it was entirely necessary to change my usual style to fit the context of the work I was doing. I changed to using 132 column terminal windows simply because the generated names were so damn long. There are probably not many "style guides" which would allow 132 column lines. What I love about using tabs for indentation is that I can easily change the appearance by adjusting the number of column positions which a tab equates to (in vim: ":set ts=3"). None of these issues (should) have anything to do with the product of your work which is source compilable to run as intended. Personal style should be left in a person's environment in a perfect world. We need a toolchain which removes it and reinserts it as it leaves and enters the personal environment. -- -Vance From ebegumisa@REDACTED Wed May 25 12:31:05 2011 From: ebegumisa@REDACTED (Edmond Begumisa) Date: Wed, 25 May 2011 20:31:05 +1000 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: <9ED39284-56EE-4FA3-9985-C806339BEAB4@dev-extend.eu> Message-ID: On Wed, 25 May 2011 06:23:38 +1000, Joe Armstrong wrote: > On Tue, May 24, 2011 at 10:02 PM, Vlad Dumitrescu > wrote: > >> One thought: modules as grouping of functions and as a unit of loading >> are >> a way to ensure that a set of functions are consistent with each other, >> relative to some data the they can work on. This is important. Whatever >> replaces them should still fullfill that requirement. >> >> regards, >> Vlad >> >> > > Absolutly. I'm working on the idea of flows. > > A flow is a list of flows or grains > > A grain is an atomic thing > > A module is basically a flow where the grains are functions. > > A novel is a flow of " chapter flows" a "chapter flow" is a flow > of paragraph grains etc. > > An image gallery is a flow of image grains. > > Everything is a flow or a grain. > > I'm wriiting a folding editor in javascript to support editing/organising > flows > > I made a weak minded attempt at this > see > https://github.com/joearms/elib1/tree/master/unsupported/folding > > In this directory are some rudimentary folding editors > test_js6.html and experiment.erl are fun. > > (( If anybody reading this is an ace javascript hacker and wants to help > please mail me -- I know *exactly* what help I need)) > > My first goal is to segement modules into flows and > put them into a web based flow editor. > > All the flows will be in a global database. > > One thing I missed saying - associated with each function is > *research* (NOT documentation) I want to store all reserach notes > necessary to write the function along with the function in a hidden fold > this should contain text, PDFs images etc. - the lot. > > Often the research to write 100 lines of codes takes weeks > and we throw all this away - this must be stored > with the code (NOT linked, store a copy, the link might be > dead years later) All my projects have a "research" folder! It contains files (NOT LINKS) of the nature you describe. It also contains text files with notes and ideas. And it's always a subdir of the "src" folder so that it's given the same priority as source files (version controlled and backed up.) - Edmond - > > /Joe -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From matthias@REDACTED Wed May 25 12:46:52 2011 From: matthias@REDACTED (Matthias Lang) Date: Wed, 25 May 2011 12:46:52 +0200 Subject: [erlang-questions] where is the best erlang pretty printer In-Reply-To: References: Message-ID: <20110525104652.GA4980@corelatus.se> On Wednesday, May 25, Joe Armstrong wrote: > I need to identify the best possible erlang pretty printer. > > Are there several, or unpublished variants in existence? > > I want exact reproduction of inputted constants > it $a should be pretty printed as $a and NOT 97. I don't understand what you want. First I thought you were asking about a source-code pretty printer, but that can't be it, surely no source code pretty printer is going to mangle $a into 97! Then I thought you wanted a replacement for io:fwrite(), but that doesn't make sense either since $a is exactly the same thing as 97 by the time it's an argument. But you know that. So you must want something else again. But what? Matt From erlang@REDACTED Wed May 25 13:37:42 2011 From: erlang@REDACTED (Joe Armstrong) Date: Wed, 25 May 2011 13:37:42 +0200 Subject: [erlang-questions] where is the best erlang pretty printer In-Reply-To: <20110525104652.GA4980@corelatus.se> References: <20110525104652.GA4980@corelatus.se> Message-ID: On Wed, May 25, 2011 at 12:46 PM, Matthias Lang wrote: > On Wednesday, May 25, Joe Armstrong wrote: > > I need to identify the best possible erlang pretty printer. > > > > Are there several, or unpublished variants in existence? > > > > I want exact reproduction of inputted constants > > it $a should be pretty printed as $a and NOT 97. > > I don't understand what you want. > Sorry - to me a pretty printer takes the AST of a parsed function, and turns into beautiful text. The text should be the same as the original source with the exception of the adjustment of white space to make the source prettier. The round trip Source -> Parse Tree -> Reconstructed Source -> ParseTree1 Should preserve certain invariants ParseTree and ParseTree1 should be isomorphic to within white space issues Syntactic variants for writing integers in Source etc. should be preserved in the reconstructed Source I guess I need not only a pretty printer but also a more precise parser - In writing this I'm wondering what to do with erlang that does not parse correctly - I know there is a pretty printer (erl_prettypr) in syntax tools - but I was wondering if there were others that I didn't know about. I guess wrangler and tidier also have some idea on prettyness. /Joe > > First I thought you were asking about a source-code pretty printer, > but that can't be it, surely no source code pretty printer is going to > mangle $a into 97! > > Then I thought you wanted a replacement for io:fwrite(), but that > doesn't make sense either since $a is exactly the same thing as 97 by > the time it's an argument. But you know that. So you must want > something else again. But what? > > Matt > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Wed May 25 13:40:08 2011 From: erlang@REDACTED (Joe Armstrong) Date: Wed, 25 May 2011 13:40:08 +0200 Subject: [erlang-questions] where is the best erlang pretty printer In-Reply-To: <4DDCCC07.2020105@cs.ntua.gr> References: <4DDCCC07.2020105@cs.ntua.gr> Message-ID: On Wed, May 25, 2011 at 11:29 AM, Kostis Sagonas wrote: > Joe Armstrong wrote: > >> I need to identify the best possible erlang pretty printer. >> >> Are there several, or unpublished variants in existence? >> >> I want exact reproduction of inputted constants >> it $a should be pretty printed as $a and NOT 97. >> > > Can you be a bit more specific on your criteria for "best" ? > "best" = what I think is prettiest - also accuracy in reconstructing the original source is important. I think the pretty printer should only manipulate white space in the program. /Joe > > Seems to that what you are asking for is not only ill-defined but pretty > much (sic!) a subjective matter... > > Kostis > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwilberding@REDACTED Wed May 25 14:36:07 2011 From: jwilberding@REDACTED (Jordan Wilberding) Date: Wed, 25 May 2011 08:36:07 -0400 Subject: [erlang-questions] Announcing ErlangCamp Boston 2011 Message-ID: Greetings, After a very successful session in Chicago last year, I am pleased to announce ErlangCamp is coming to Boston! ErlangCamp will again be a 2-day event, occuring on Friday, August 12th through Saturday, August 13th. The event will be held at the John Hancock Hotel & Conference Center. For those unfamiliar, ErlangCamp is a two day hands on workshop for those interested in learning how to go from novices or experienced levels of programming Erlang to being able to confidently write production grade Erlang/OTP services. ErlangCamp is an opportunity to learn from those who have done a ton with OTP and Erlang and put many many lines of code into production at companies ranging from huge to small. The curriculum will roughly follow the progression from the book "Erlang and OTP in Action" at http://manning.com/logan but present a ton of new material from a different angle. When you leave you will know how to confidently put massively parallel, fault tolerant, distributed Erlang/OTP applications into production and then manage them from there. To register and find out more information, please goto: http://erlangcamp.com/ Thanks! Jordan Wilberding -------------- next part -------------- An HTML attachment was scrubbed... URL: From sigmastar@REDACTED Wed May 25 15:21:41 2011 From: sigmastar@REDACTED (Jesse Gumm) Date: Wed, 25 May 2011 08:21:41 -0500 Subject: [erlang-questions] Announcing ErlangCamp Boston 2011 In-Reply-To: Message-ID: <4ddd026a.4899ec0a.7f90.4388@mx.google.com> Congrats! ErlangCamp chicago was awesome and I hope it goes just as well in Boston. All the best, -Jesse -- Jesse Gumm Sigma Star Systems 414.940.4866 On May 25, 2011 7:36 AM, Jordan Wilberding <jwilberding@REDACTED> wrote: Greetings, After a very successful session in Chicago last year, I am pleased to announce ErlangCamp is coming to Boston! ErlangCamp will again be a 2-day event, occuring on Friday, August 12th through Saturday, August 13th. The event will be held at the John Hancock Hotel & Conference Center. For those unfamiliar, ErlangCamp is a two day hands on workshop for those interested in learning how to go from novices or experienced levels of programming Erlang to being able to confidently write production grade Erlang/OTP services. ErlangCamp is an opportunity to learn from those who have done a ton with OTP and Erlang and put many many lines of code into production at companies ranging from huge to small. The curriculum will roughly follow the progression from the book "Erlang and OTP in Action" at http://manning.com/logan but present a ton of new material from a different angle. When you leave you will know how to confidently put massively parallel, fault tolerant, distributed Erlang/OTP applications into production and then manage them from there. To register and find out more information, please goto: http://erlangcamp.com/ Thanks! Jordan Wilberding -------------- next part -------------- An HTML attachment was scrubbed... URL: From egil@REDACTED Wed May 25 16:06:02 2011 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Wed, 25 May 2011 16:06:02 +0200 Subject: [erlang-questions] Erlang/OTP R14B03 has been released Message-ID: <4DDD0CCA.7000807@erix.ericsson.se> Erlang/OTP R14B03 has been released. This release is mainly a stabilization of the R14B03 release (but as usual there are some new functionality as well). You can find the README file for the release at http://www.erlang.org/download/otp_src_R14B03.readme The source distribution and binary distribution for Windows can be downloaded from http://www.erlang.org/download/otp_src_R14B03.tar.gz http://www.erlang.org/download/otp_win32_R14B03.exe Note: To unpack the TAR archive you need a GNU TAR compatible program. For installation instructions please read the README file that is part of the distribution. You can also find the source in the official Erlang/OTP git-repository at GitHub (http://github.com/erlang/otp) The on-line documentation can be found at: http://www.erlang.org/doc/ You can also download the complete HTML documentation or the Unix manual files http://www.erlang.org/download/otp_doc_html_R14B03.tar.gz http://www.erlang.org/download/otp_doc_man_R14B03.tar.gz We also want to thank those that sent us patches, suggestions and bug reports. The Erlang/OTP Team Ericsson AB From gnoblin@REDACTED Wed May 25 16:10:10 2011 From: gnoblin@REDACTED (Slav Pankratov) Date: Wed, 25 May 2011 17:10:10 +0300 Subject: [erlang-questions] Erlang/OTP R14B03 has been released In-Reply-To: <4DDD0CCA.7000807@erix.ericsson.se> References: <4DDD0CCA.7000807@erix.ericsson.se> Message-ID: Hello! I am Erlang newbie, what's "Diameter"? thanks, Slav -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.kleberg@REDACTED Wed May 25 16:14:50 2011 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Wed, 25 May 2011 16:14:50 +0200 Subject: [erlang-questions] Erlang/OTP R14B03 has been released In-Reply-To: References: <4DDD0CCA.7000807@erix.ericsson.se> Message-ID: <1306332890.5874.39.camel@seasc1137> http://en.wikipedia.org/wiki/Diameter_(protocol) On Wed, 2011-05-25 at 16:10 +0200, Slav Pankratov wrote: > Hello! > > > I am Erlang newbie, what's "Diameter"? > > > thanks, > Slav From nick@REDACTED Wed May 25 16:20:11 2011 From: nick@REDACTED (Niclas Eklund) Date: Wed, 25 May 2011 16:20:11 +0200 Subject: [erlang-questions] Erlang/OTP R14B03 has been released In-Reply-To: <4DDD0CCA.7000807@erix.ericsson.se> References: <4DDD0CCA.7000807@erix.ericsson.se> Message-ID: Hello! A security vulnerability in the SSH application has recently been discovered and fixed (thanks to Geoff Cant!). This fix is included in R14B03, which is why you should consider upgrading if you use SSH. A detailed description can be found via http://www.cert.org/ Search for Vulnerability Note - VU#178990 (should be published soon). Best Regards, Niclas @ Erlang/OTP On Wed, 25 May 2011, Bj?rn-Egil Dahlberg wrote: > Erlang/OTP R14B03 has been released. > > This release is mainly a stabilization of the R14B03 release (but as usual > there are some new functionality as well). > > You can find the README file for the release at > > http://www.erlang.org/download/otp_src_R14B03.readme > > The source distribution and binary distribution for Windows can be downloaded > from > > http://www.erlang.org/download/otp_src_R14B03.tar.gz > http://www.erlang.org/download/otp_win32_R14B03.exe > > > Note: To unpack the TAR archive you need a GNU TAR compatible program. > > For installation instructions please read the README file that is part > of the distribution. > > You can also find the source in the official Erlang/OTP git-repository at > GitHub (http://github.com/erlang/otp) > > > The on-line documentation can be found at: http://www.erlang.org/doc/ > You can also download the complete HTML documentation or the Unix manual > files > > http://www.erlang.org/download/otp_doc_html_R14B03.tar.gz > http://www.erlang.org/download/otp_doc_man_R14B03.tar.gz > > We also want to thank those that sent us patches, suggestions and bug > reports. > > The Erlang/OTP Team > Ericsson AB > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From nick@REDACTED Wed May 25 16:35:20 2011 From: nick@REDACTED (Niclas Eklund) Date: Wed, 25 May 2011 16:35:20 +0200 Subject: [erlang-questions] Erlang/OTP R14B03 has been released In-Reply-To: References: <4DDD0CCA.7000807@erix.ericsson.se> Message-ID: Hi! The Vulnerability Note is now available - http://www.kb.cert.org/vuls/id/178990 Best Regards, Niclas @ Erlang/OTP On Wed, 25 May 2011, Niclas Eklund wrote: > > Hello! > > A security vulnerability in the SSH application has recently been discovered > and fixed (thanks to Geoff Cant!). This fix is included in R14B03, which is > why you should consider upgrading if you use SSH. A detailed description can > be found via http://www.cert.org/ Search for Vulnerability Note - VU#178990 > (should be published soon). > > Best Regards, > > Niclas @ Erlang/OTP > > > On Wed, 25 May 2011, Bj?rn-Egil Dahlberg wrote: > >> Erlang/OTP R14B03 has been released. >> >> This release is mainly a stabilization of the R14B03 release (but as usual >> there are some new functionality as well). >> >> You can find the README file for the release at >> >> http://www.erlang.org/download/otp_src_R14B03.readme >> >> The source distribution and binary distribution for Windows can be >> downloaded from >> >> http://www.erlang.org/download/otp_src_R14B03.tar.gz >> http://www.erlang.org/download/otp_win32_R14B03.exe >> >> >> Note: To unpack the TAR archive you need a GNU TAR compatible program. >> >> For installation instructions please read the README file that is part >> of the distribution. >> >> You can also find the source in the official Erlang/OTP git-repository at >> GitHub (http://github.com/erlang/otp) >> >> >> The on-line documentation can be found at: http://www.erlang.org/doc/ >> You can also download the complete HTML documentation or the Unix manual >> files >> >> http://www.erlang.org/download/otp_doc_html_R14B03.tar.gz >> http://www.erlang.org/download/otp_doc_man_R14B03.tar.gz >> >> We also want to thank those that sent us patches, suggestions and bug >> reports. >> >> The Erlang/OTP Team >> Ericsson AB >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > From ulf.wiger@REDACTED Wed May 25 16:41:44 2011 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Wed, 25 May 2011 16:41:44 +0200 Subject: [erlang-questions] Erlang/OTP R14B03 has been released In-Reply-To: <4DDD0CCA.7000807@erix.ericsson.se> References: <4DDD0CCA.7000807@erix.ericsson.se> Message-ID: <1E84DA99-C2BF-4388-983F-6BD84A8FF802@erlang-solutions.com> Reading "OTP-9214 epmd: include host address in local access check" I recall that I submitted a patch last year that did something similar to this, but (if I understand right) seems more generic. http://erlang.org/pipermail/erlang-patches/2010-May/001041.html "Allow the erlang nodename host part to differ from the hostname" It stalled because I didn't submit docs and test cases, which I didn't because there was never any feedback from anyone, nor any replies to my queries about how it might be tested and documented. So here goes again: is my patch made redundant by this recent fix? Are they incompatible? Orthogonal? Would it still be interesting to complete the previous patch? BR, Ulf W On 25 May 2011, at 16:06, Bj?rn-Egil Dahlberg wrote: > Erlang/OTP R14B03 has been released. > > This release is mainly a stabilization of the R14B03 release (but as usual there are some new functionality as well). > > You can find the README file for the release at > > http://www.erlang.org/download/otp_src_R14B03.readme ? Ulf Wiger, CTO, Erlang Solutions, Ltd. http://erlang-solutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlo.bertoldi@REDACTED Wed May 25 17:07:00 2011 From: carlo.bertoldi@REDACTED (Carlo Bertoldi) Date: Wed, 25 May 2011 17:07:00 +0200 Subject: [erlang-questions] Mnesia and network partitions Message-ID: <4DDD1B14.3050103@ubiquity.it> Hi everybody, I've got a mnesia schema on two nodes. I connected the nodes, added some data, then disconnected the nodes, in order to simulate a network split. I changed some data in the slave node, then reconnected the nodes and obtained the expected message (** ERROR ** mnesia_event got {inconsistent_database, running_partitioned_network, node@REDACTED}). The problem is that the data on the slave node is still different from the data in the master node. I did set the master node with mnesia:set_master_nodes(), since I understand that this should be enough to get the changes automatically overwritten upon reconnection. Thanks, Carlo From ulf.wiger@REDACTED Wed May 25 17:17:07 2011 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Wed, 25 May 2011 17:17:07 +0200 Subject: [erlang-questions] Mnesia and network partitions In-Reply-To: <4DDD1B14.3050103@ubiquity.it> References: <4DDD1B14.3050103@ubiquity.it> Message-ID: <259C14D7-E96B-4CF0-91AB-CD08D86B30D9@erlang-solutions.com> Setting master nodes will ensure that restarting nodes will unconditionally load from the masters. In order for this to make a difference after netsplit, you have to restart the nodes that should synch to the remaining nodes. This could be triggered by the inconsistent_database event. An alternative would be to use http://github.com/esl/unsplit (apologies for the lack of documentation), which makes it possible to recover from netsplits through merge without restarts. As of R14B03, there is also a feature to enforce (per table) that updates will only succeed if it can be committed on a majority of the replicas. This can be used to minimize the risk of fatal inconsistencies at netsplit. BR, Ulf W On 25 May 2011, at 17:07, Carlo Bertoldi wrote: > Hi everybody, > I've got a mnesia schema on two nodes. I connected the nodes, added some data, then > disconnected the nodes, in order to simulate a network split. > I changed some data in the slave node, then reconnected the nodes and obtained > the expected message (** ERROR ** mnesia_event got {inconsistent_database, > running_partitioned_network, node@REDACTED}). > The problem is that the data on the slave node is still different from the data in the master node. > I did set the master node with mnesia:set_master_nodes(), since I understand that this should be enough to get the changes automatically overwritten upon reconnection. > > Thanks, > Carlo > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions Ulf Wiger, CTO, Erlang Solutions, Ltd. http://erlang-solutions.com From ttom.kelly@REDACTED Wed May 25 17:35:55 2011 From: ttom.kelly@REDACTED (tom kelly) Date: Wed, 25 May 2011 16:35:55 +0100 Subject: [erlang-questions] Upgrading TCP connection to SSL Message-ID: Hello List, I've been reading the SSL documentation on upgrading a TCP connection to use SSL: http://www.erlang.org/doc/apps/ssl/using_ssl.html I've got a situation where I've accepted a TCP connection which the connector has initiated using SSL. It seems I can't at this point upgrade my TCP connection to SSL using the standard SSL library? If I understand the documentation correctly I need to be in control of both ends of the connection to correctly execute this upgrade and in my application I'll never be in control of the connecting side. Does anyone know if this is correct or see something that I'm missing? Anyone know any hack-arounds? Thanks in advance. //Tom. -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam@REDACTED Wed May 25 18:16:28 2011 From: adam@REDACTED (Adam Lindberg) Date: Wed, 25 May 2011 18:16:28 +0200 Subject: [erlang-questions] Mocking I/O calls - defining sequence of returns In-Reply-To: <4DDB7B44.8030801@erlang-solutions.com> References: <312F7919-F0D3-4BDB-AA0F-73951D42209A@gmail.com> <4DDB7B44.8030801@erlang-solutions.com> Message-ID: <4DDD2B5C.4050909@erlang-solutions.com> I've added something more lightweight to meck's official repo now in version 0.6 which might solve your problem. See the two commits: https://github.com/eproxus/meck/commit/35de01e https://github.com/eproxus/meck/commit/8d86012 It's the functions sequence/4 and loop/4 which works almost the same as expect/4 except that they return one value at a time from the list given as input (sequence will exhaust it and stick to the last element, and loop will loop the results infinitely). Cheers, Adam Adam Lindberg wrote: > Hi, > > Spurred by the discussion, I did take a look at implementing this in > meck. There are a few alternatives to simulating state in mocks: > > * Using the process dictionary > - Pros: fast, simple, easy to understand > - Cons: not "thread safe", no transactions > > * Implement your own state in another process, used by the mock > - Pros: fast, simple > - Cons: can be made specific for the test case and thus needs less > locking > > * Keeping state in the actual mock (a process in meck's case) > - Pros: Can be made "thread safe" > - Cons: slow (will lock process for each call to mock) > You cannot do a mock with fun() -> timer:sleep(infinity) end, > for example. > > The latter means that for a test program to be able to manipulate the > mock (add expectations or get history) no code must be using the mock > (since the mock process is blocked for the duration of the call to the > mock, to be able to guarantee transactional state changes). > > I did a reference implementation of this and it got a bit messy in a few > different edge scenarios, but it works. > > I did implement the synchronized state which has the cons described > above. A simpler earlier version which I tested first had a much neater > implementation but did not synchronize puts/gets between calls (similar > to using the process dictionary, except that it was using the dictionary > of the mock process instead). > > You can check out the latest implementation here: > https://github.com/eproxus/meck/tree/put-get > > The branch adds meck:put/2 and meck:get/1 to be used inside mocks. A new > option can be passed to meck:new/2 which initializes the dictionary: > > meck:new(mymod, [{dict, {a, 0}}]), > meck:expect(mymod, test, fun() -> meck:put(a, meck:get(a) + 1) end), > 0 = mymod:test(), > 1 = mymod:test(), > 2 = mymod:test(), > % etc > > You can see the "breakage" created by looking at the uncommented test > case. Performance has not been looked at at all. > > Cheers, > Adam > > > > Tim Watson wrote: >> On 23 May 2011 10:51, Dmitry Demeshchuk wrote: >>> You can use meck and process dictionary combination, for example: >> >> That's a bit dangerous if the module under test gets called from >> multiple processes though, which is often (perhaps even normally?) the >> case. For very simple cases it might be ok though, as you say. >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions From michael.santos@REDACTED Wed May 25 18:36:59 2011 From: michael.santos@REDACTED (Michael Santos) Date: Wed, 25 May 2011 12:36:59 -0400 Subject: [erlang-questions] Erlang/OTP R14B03 has been released In-Reply-To: <1E84DA99-C2BF-4388-983F-6BD84A8FF802@erlang-solutions.com> References: <4DDD0CCA.7000807@erix.ericsson.se> <1E84DA99-C2BF-4388-983F-6BD84A8FF802@erlang-solutions.com> Message-ID: <20110525163659.GD3544@ecn.lan> On Wed, May 25, 2011 at 04:41:44PM +0200, Ulf Wiger wrote: > > Reading "OTP-9214 epmd: include host address in local access check" > > I recall that I submitted a patch last year that did something similar to this, but (if I understand right) seems more generic. > > http://erlang.org/pipermail/erlang-patches/2010-May/001041.html > "Allow the erlang nodename host part to differ from the hostname" > > It stalled because I didn't submit docs and test cases, which I didn't because there was never any feedback from anyone, nor any replies to my queries about how it might be tested and documented. > > So here goes again: is my patch made redundant by this recent fix? Are they incompatible? Orthogonal? Would it still be interesting to complete the previous patch? The patches don't overlap. At some point, epmd was restricted to accept certain commands (like registration, stopping epmd) only from connections on the loopback. This patch relaxes the check to consider connections with the same source and destination addresses as local. From moxford@REDACTED Wed May 25 18:49:35 2011 From: moxford@REDACTED (Mike Oxford) Date: Wed, 25 May 2011 09:49:35 -0700 Subject: [erlang-questions] System timers, now/0, and instrumentation In-Reply-To: References: <673380092.213661306227737701.JavaMail.root@zimbra> <20110525090730.GA6149@erix.ericsson.se> Message-ID: Write a port driver to a serial-based external timer. Maybe an atomic clock. =P -mox On Wed, May 25, 2011 at 2:21 AM, Amy Lear wrote: > On Wed, May 25, 2011 at 2:07 AM, Raimo Niskanen > wrote: > > The reason the provided profiling tools rely on now/0 is mostly > > that it has been around as long as they, plus the fact that > > now/0 never moves backwards, mostly moves forwards kind > > of sanely and is fairly lightweight makes it a nice but possibly > > somewhat inaccurate compromise for a generic profiling tool. > > This makes sense. > > > No. There is currenly nothing better built in than erlang:now/0 and > > os:timestamp/0. They could probably be improved on Windows but it > > was quite a while since we had anyone requiring (as in providing > > resources) us developing Erlang for Windows. > > > > Side note: timer:tc/2,3 is about / has been converted to use > > os:timestamp/0 instead. > > Okay, good to know. I'm continuing to look into it from my end, and > maybe I'll find something that could be usable to other people. > > Thanks for your time and attention. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fritchie@REDACTED Wed May 25 19:54:34 2011 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Wed, 25 May 2011 12:54:34 -0500 Subject: [erlang-questions] QuickCheck/PropEr In-Reply-To: Message of "Wed, 25 May 2011 13:25:26 +1000." Message-ID: <70560.1306346074@snookles.snookles.com> Edmond Begumisa wrote: eb> This looks like a good case-study. I will analyse it fully. Quick eb> one: are there any properties on gen_servers in here? Specifically for gen_server, hrm, probably not. But it isn't all that difficult to do. prop_server_doesnt_crash(InitArgs) -> ?FORALL(Commands, gen_my_servers_commands(), begin {ok, Pid} = my_server:start(InitArgs), [_ = apply(Mod, Func, Args) || {Mod, Fun, Args} <- Commands], Result = erlang:is_process_alive(Pid), catch my_server:please_stop_now(Pid), Result end). If you want to check if the server is really sane, add a testing-use-only command to fetch the server's internal state and replace the last 3 lines with: FinalState = my_server:get_internal_state(Pid), my_server:please_stop_now(Pid), verify_sanity(FinalState) %% returns boolean() The hassle of cleaning up after each test (killing the process under test) is a pain(*). As Joe Norton pointed out, there's nothing that prevents you from testing calls directly against your behavior's callback module, i.e. calling my_server:handle_call/3 directly; you'll have to do something more fold-like than the simple list-comprehension- with-apply in the above example, but it's easy enough to do. When testing via behavior callback functions, you'll only be testing the server-side code and not any client-side code (e.g. calculations done before a gen_server:call(), gen_server:cast(), or '!'). That might be good, might be not good enough, depends on the purpose of the tests. -Scott (*) Testing code with any side-effects at all can cause difficulty. In the example below, just creating a new process is certainly a side-effect. Many gen_servers register a process name; if your test framework doesn't clean up those processes 100% correctly(**), then later tests can fail because a call to erlang:register/2 fails. (**) Of course, that's also a problem when using EUnit, or your own test tools, etc. From kaiduanx@REDACTED Wed May 25 20:00:07 2011 From: kaiduanx@REDACTED (Kaiduan Xie) Date: Wed, 25 May 2011 14:00:07 -0400 Subject: [erlang-questions] Upgrading TCP connection to SSL In-Reply-To: References: Message-ID: For TCP upgrading to SSL, client and server coordination is required. The following is used in XMPP protocol, 1) Client initiates TCP connection, 2) Server accepts the TCP connection, 3) Server sends a message to client to notify client that server supports TCP upgrade to SSL, 4) Client receives the feature notification from server, and then client sends starttls to server, 5) Upon receiving starttls from client, server sends back proceed to client, server waits for SSL handshake, 6) Upon receiving proceed from server, client starts SSL handshake with server. For more details please refer 5.3. Client-to-Server Example www.ietf.org/rfc/rfc3290.txt Thanks, /Kaiduan On Wed, May 25, 2011 at 11:35 AM, tom kelly wrote: > Hello List, > > I've been reading the SSL documentation on upgrading a TCP connection to use > SSL: > http://www.erlang.org/doc/apps/ssl/using_ssl.html > > I've got a situation where I've accepted a TCP connection which the > connector has initiated using SSL. It seems I can't at this point upgrade my > TCP connection to SSL using the standard SSL library? > If I understand the documentation correctly I need to be in control of both > ends of the connection to correctly execute this upgrade and in my > application I'll never be in control of the connecting side. > > Does anyone know if this is correct or see something that I'm missing? > Anyone know any hack-arounds? > > Thanks in advance. > > //Tom. > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > From octopusfluff@REDACTED Wed May 25 20:07:46 2011 From: octopusfluff@REDACTED (Amy Lear) Date: Wed, 25 May 2011 11:07:46 -0700 Subject: [erlang-questions] System timers, now/0, and instrumentation In-Reply-To: References: <673380092.213661306227737701.JavaMail.root@zimbra> <7C243B92-39B6-4DB3-9D65-4E7538AD7B57@cs.otago.ac.nz> Message-ID: On Wed, May 25, 2011 at 1:20 AM, Amy Lear wrote: > On Tue, May 24, 2011 at 11:45 PM, Richard O'Keefe wrote: >> Er, there's a problem with the performance counters, isn't there? >> now() is supposed to give you a clock, something that ticks >> regularly. >> The performance counters count events in the CPU, and today's >> power-sensitive CPUs do things like scaling back the CPU clock >> frequency when they think they aren't busy. >> >> I know people keep telling me that time monitoring using cpu >> cycle counters doesn't work any more; I can't say of my own knowledge >> whether they are right. > > According to msdn, QueryPerformanceCounter() is the solution to problems > like RDTSC slipping in power management ( > http://msdn.microsoft.com/en-us/library/ee417693%28v=vs.85%29.aspx circa > 2005), but some later discussions ( > http://www.red-gate.com/supportcenter/Content?p=ANTS%20Performance%20Profiler&c=ANTS_Performance_Profiler\knowledgebase\app_speedstep.htm > ) suggest that newer power management techniques (such as AMD cool'n'quiet) > could defeat the efforts of that timer to maintain a steady beat. It's hard > to tell if that has been addressed by Microsoft or not since then. > > I'm really at a loss as to what the right solution here could be. I have > trouble imagining there isn't one, but I'm not well-versed enough in the > architecture to know where else to look. > > I do know that right now there is a higher resolution timer available than > what now/0 uses, but I'm not clear on what the performance penalty of > os:timestamp/0 is in comparison, and I wouldn't know how to properly measure > it. Okay! I've done some more research, and gotten into contact with some folks who've had to deal with high resolution timers on multiple platforms, and it turns out that the issues with AMD and QueryPerformanceCounter have been resolved. So the correct answer does appear to be to use QueryPerformanceFrequency ( http://msdn.microsoft.com/en-us/library/ms644905.aspx ) to determine the highest resolution clock available to you on the current machine -- msdn claims this will never change while the machine is running -- then use QueryPerformanceCounter ( http://msdn.microsoft.com/en-us/library/ms644904 ) for the current count. Of course this is time since system start, not a timestamp, but determining the math needed to convert QPC beats into timestamps on each initialization of the erlang system shouldn't be too difficult. In theory. I could do this as a port, but it'd be really nice if eventually now/0 could incorporate this. Using the standard instrumentation framework would be helpful for me and I'm sure eventually someone else will be testing on Windows as well. It's happened before, after all. From karol.skocik@REDACTED Wed May 25 20:58:22 2011 From: karol.skocik@REDACTED (karol skocik) Date: Wed, 25 May 2011 20:58:22 +0200 Subject: [erlang-questions] how to remove failed node from mnesia schema ? Message-ID: Hi, this should be solvable, but I can't google anything. The situation, in distributed mnesia: 1.) node A starts 2.) node B starts, creates table T, ram_copy, only on node B. (schema table now contains T) 3.) node B crashes 4.) node B is started again, and wants to either: a.) create fresh table B, if no other node C already has ram_copy of T b.) add_table_copy, if some node C has ram_copy of T but, the situation is somehow, not intuitive. When I check schema with ets:i(schema) or mnesia:table_info, I see table T there. > mnesia:table_info(T, all). [{access_mode,read_write}, {active_replicas,[]}, {arity,3}, ....] But I can't really do anything with it! Delete table fails (on both A and B): > mnesia:delete_table(T). {aborted,{no_exists,'waiting_task.type.2'}} I can't do del_table_copy (on B, where was T originally created before it crashed): > mnesia:del_table_copy(T, node()). {aborted,{no_exists,'waiting_task.type.2'}} Additionally, I can't "recreate" the table again (silly, I know): (slave@REDACTED)20> Nodes = [node()]. [slave@REDACTED] (slave@REDACTED)21> Def = [{type, ordered_set}, (slave@REDACTED)21> {ram_copies, Nodes}, (slave@REDACTED)21> {record_name, tq_entry}, (slave@REDACTED)21> {attributes, record_info(fields, tq_entry)}]. (slave@REDACTED)22> mnesia:create_table(T, Def). {aborted,{already_exists,'waiting_task.type.2'}} Now, modifying schema table directly fails: > mnesia:transaction(fun () -> mnesia:delete({schema, T}) end). {aborted,{bad_type,schema}} So, what should I do to remove crashed node from schema? Thanks for any ideas! Karol From mjtruog@REDACTED Wed May 25 22:41:28 2011 From: mjtruog@REDACTED (Michael Truog) Date: Wed, 25 May 2011 13:41:28 -0700 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: <9ED39284-56EE-4FA3-9985-C806339BEAB4@dev-extend.eu> Message-ID: <4DDD6978.8090604@gmail.com> On 05/25/2011 02:26 AM, Tim Watson wrote: > So you're sort of correct. The specs are present in the abstract_code > chunk. I'm guessing this will only be the case if (a) you've compiled > with debug_info and/or (b) you've used the abstract_code > parse_transform (from github?) to ensure it's present either way. There is a copy of the abstract_code parse transform here: https://github.com/okeuday/CloudI/blob/master/src/lib/unused/src/abstract_code.erl That method is better than the debug_info route. From gregory.haskins@REDACTED Wed May 25 22:46:54 2011 From: gregory.haskins@REDACTED (Gregory Haskins) Date: Wed, 25 May 2011 16:46:54 -0400 Subject: [erlang-questions] Managing object lifetimes from NIF Message-ID: <4DDD6ABE.4070501@gmail.com> Hi All, Is it possible to safely retain references to objects like an ERL_NIF_TERM inside a NIF resource? For instance, can I have struct myresource { ErlNifPid *pid; ERL_NIF_TERM *term; }; and allocate this structure with enif_alloc_resource in such a way that I can ensure (either implicitly or explictly) that pid/term are properly reference counted till at least the dtor is called on my resource? Thanks! -Greg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 267 bytes Desc: OpenPGP digital signature URL: From gregory.haskins@REDACTED Wed May 25 22:51:44 2011 From: gregory.haskins@REDACTED (Gregory Haskins) Date: Wed, 25 May 2011 16:51:44 -0400 Subject: [erlang-questions] Managing object lifetimes from NIF In-Reply-To: <4DDD6ABE.4070501@gmail.com> References: <4DDD6ABE.4070501@gmail.com> Message-ID: <4DDD6BE0.40601@gmail.com> On 5/25/11 4:46 PM, Gregory Haskins wrote: > Hi All, > > Is it possible to safely retain references to objects like an > ERL_NIF_TERM inside a NIF resource? > > For instance, can I have > > struct myresource { > ErlNifPid *pid; > ERL_NIF_TERM *term; > }; > > and allocate this structure with enif_alloc_resource in such a way that > I can ensure (either implicitly or explictly) that pid/term are properly > reference counted till at least the dtor is called on my resource? > > Thanks! > -Greg > > NM, I think I figured it out. I think the answer is that I want to create a custom ErlNifEnv created by enif_alloc_env() and use that for the resource's contained objects. Thanks all, -Greg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 267 bytes Desc: OpenPGP digital signature URL: From pablo.platt@REDACTED Thu May 26 01:56:16 2011 From: pablo.platt@REDACTED (Pablo Platt) Date: Wed, 25 May 2011 16:56:16 -0700 (PDT) Subject: [erlang-questions] uninstall or upgrade after building from source Message-ID: <329133.90799.qm@web112614.mail.gq1.yahoo.com> Hi How do I uninstall erlang after building and installing from source? The readme doesn't say anything about uninstall/upgrade and the MakeFile doesn't have uninstall role. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From jws@REDACTED Thu May 26 05:56:45 2011 From: jws@REDACTED (Jeff Schultz) Date: Thu, 26 May 2011 13:56:45 +1000 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: References: Message-ID: <20110526035645.GA12425@mulga.csse.unimelb.edu.au> On Tue, May 24, 2011 at 10:06:19AM +0200, Joe Armstrong wrote: > functions are really easy to reuse > modules are more difficult to reuse Just to comment on this described contrast, consider a synthetic example: create(X) -> {classify(X), X}. consume({C, X}) -> C = classify(X), io:format("~p~n", [X]). classify(X) when X > 0 -> positive; classify(X) when X < 0 -> negative. This program has a bug, at least for our present purposes. It's also rather pointless. Imagine that classify/1 produced a cryptographically strong message authenticator instead, if desired. Now, normally, we'd put the three functions in a module, say 'm', and call them from another module thus test(X) -> W = m:create(X), m:consume(W). When we fix the bug in classify/1 by adding a clause classify(0) -> zero; and reload m, we can now call test(0) successfully. If, instead, we have each function living in isolation in a global namespace, we might be able to get away with just reloading classify/1, but we didn't even know we were using it! If we reload create/1, we just move the crash to the consume/1 call. See, modules are easy to reuse, and functions are hard ;-) The thing we need to keep from modules as they are now is this connection between groups of functions that must be used together. I think that if we wrote the example instead as let classify(X) . . . in create(X) . . . and consume(X) . . . . we're just providing an alternate syntax for the existing module definition in which the module name has become implicit. Joe's proposal sounds fun, and might work very well once people adjust, but the metadata is going to have to be worked very hard, and Erlang's remote expression will have to use it too. Jeff Schultz From max.lapshin@REDACTED Thu May 26 06:11:12 2011 From: max.lapshin@REDACTED (Max Lapshin) Date: Thu, 26 May 2011 08:11:12 +0400 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: <20110526035645.GA12425@mulga.csse.unimelb.edu.au> References: <20110526035645.GA12425@mulga.csse.unimelb.edu.au> Message-ID: In fact nobody distributes modules: people organize functions into classes or modules and packs them into libraries. Libraries are units of distribution. It is the only way for programmer to somehow lower complexity. I would never be able to select what functions I may need from OTP, but I may understand what libraries does it consist of. I still see no profit from making php-link function naming hell in erlang. From jeffm@REDACTED Thu May 26 07:52:54 2011 From: jeffm@REDACTED (jm) Date: Thu, 26 May 2011 15:52:54 +1000 Subject: [erlang-questions] Why do we need modules at all? In-Reply-To: <614E64ED-5E5B-40B9-AFF5-463C247087D3@cs.otago.ac.nz> References: <4DDC9ED0.9090900@ghostgun.com> <614E64ED-5E5B-40B9-AFF5-463C247087D3@cs.otago.ac.nz> Message-ID: <4DDDEAB6.2040808@ghostgun.com> On 25/05/11 5:30 PM, Richard O'Keefe wrote: > > The original Smalltalk ran on bare metal. > > Interlisp-D ran on bare metal. > > Lisp machines ditto. > > Lisp is definitely more than an AST written in ASCII, and > there are several Algol-ish front ends for it. Reduce > has (had?) RLisp and Macsyma used CGOL, I think. > > The Poplog system ran under VMS, and because they were Thanks. Now I've got some names I'll do a few searches and read up on these. It will be interesting to see how they bootstrapped the set up, grew the runtime environment and if they changed the grammar or behaviour of the language as they moved away from the bare metal. I don't mean to be hard on LISP and the SICP seems to be one of those books on my reading queue that I never get to. It seems that it's the standard answer to problems that "no-one" uses. An Algol-ish front end is an intriguing idea if done cleanly. The other language that I expected to hear was Forth which was getting used a lot in embedded applications years ago. It would be interesting to create some form of plot featuring such things as soft real-time, hard real-time, batch, kernel programming, gui programming, system management, etc and see if there's a logical progression of any form in the desirable or used language/environment features. All this is something for another time I fear. Jeff. From ingela@REDACTED Thu May 26 10:01:06 2011 From: ingela@REDACTED (Ingela Andin) Date: Thu, 26 May 2011 10:01:06 +0200 Subject: [erlang-questions] Upgrading TCP connection to SSL In-Reply-To: References: Message-ID: Hi! As Kaiduan points out you need a scheme (agreed upon protocol) to coordinate the upgrade but of course you do not need to control both sides of the connection. In the upgrade example we show a upgrade scenario, issuing commands from two erlang shells, demonstrating the mechanism on the "erlang-ssl" level. Of course we use the erlang client and server to show how our software should be used, does not mean you can not use any other ssl client to connect to our server or vice versa. See for instance RFC 2817 to see how it is done in HTTP/1.1 Regards Ingela Erlang/OTP team - Ericsson AB 2011/5/25 Kaiduan Xie : > For TCP upgrading to SSL, client and server coordination is required. > The following is used in XMPP protocol, > > 1) Client initiates TCP connection, > 2) Server accepts the TCP connection, > 3) Server sends a message to client to notify client that server > supports TCP upgrade to SSL, > 4) Client receives the feature notification from server, and then > client sends starttls to server, > 5) Upon receiving starttls from client, server sends back proceed to > client, server waits for SSL handshake, > 6) Upon receiving proceed from server, client starts SSL handshake with server. > > For more details please refer 5.3. ?Client-to-Server Example > > www.ietf.org/rfc/rfc3290.txt > > Thanks, > > /Kaiduan > > On Wed, May 25, 2011 at 11:35 AM, tom kelly wrote: >> Hello List, >> >> I've been reading the SSL documentation on upgrading a TCP connection to use >> SSL: >> http://www.erlang.org/doc/apps/ssl/using_ssl.html >> >> I've got a situation where I've accepted a TCP connection which the >> connector has initiated using SSL. It seems I can't at this point upgrade my >> TCP connection to SSL using the standard SSL library? >> If I understand the documentation correctly I need to be in control of both >> ends of the connection to correctly execute this upgrade and in my >> application I'll never be in control of the connecting side. >> >> Does anyone know if this is correct or see something that I'm missing? >> Anyone know any hack-arounds? >> >> Thanks in advance. >> >> //Tom. >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From nox@REDACTED Thu May 26 11:24:16 2011 From: nox@REDACTED (Anthony Ramine) Date: Thu, 26 May 2011 11:24:16 +0200 Subject: [erlang-questions] Multiple types with the same name in Dialyzer Message-ID: <96B869B4-4B4A-444F-8294-81C737F61D9B@dev-extend.eu> Hi, I have a type value/1 defined as `-type value(LabelT) :: ...` and I would like to have a type value/0 with a default LabelT type value like `-type value() :: value(binary())`. The file compiles just fine but Dialyzer complains that "Type value is already defined". This exception is thrown from dialyzer_utils:add_new_type/6 [1] because the arity is not a part of a type identity, you can see this in erl_types:type_is_defined/3 [2]. What I really don't understand is that while the arity is not a part of it, whether the given type is opaque or not is, so you can have both `-type t()` and `-opaque t()`. So I have two questions: - Is being unable to have both type value/0 and value/1 a bug? - Does being able to have both type t opaque and non-opaque have any purpose? Regards, [1] https://github.com/erlang/otp/blob/dev/lib/dialyzer/src/dialyzer_utils.erl#L223 [2] https://github.com/erlang/otp/blob/dev/lib/hipe/cerl/erl_types.erl#L3984 -- Anthony Ramine Dev:Extend http://dev-extend.eu From kostis@REDACTED Thu May 26 11:24:58 2011 From: kostis@REDACTED (Kostis Sagonas) Date: Thu, 26 May 2011 12:24:58 +0300 Subject: [erlang-questions] Multiple types with the same name in Dialyzer In-Reply-To: <96B869B4-4B4A-444F-8294-81C737F61D9B@dev-extend.eu> References: <96B869B4-4B4A-444F-8294-81C737F61D9B@dev-extend.eu> Message-ID: <4DDE1C6A.60303@cs.ntua.gr> Anthony Ramine wrote: > Hi, > > I have a type value/1 defined as `-type value(LabelT) :: ...` and I would > like to have a type value/0 with a default LabelT type value like > `-type value() :: value(binary())`. The file compiles just fine but Dialyzer > complains that "Type value is already defined". > > This exception is thrown from dialyzer_utils:add_new_type/6 [1] because the arity > is not a part of a type identity, you can see this in erl_types:type_is_defined/3 [2]. > > What I really don't understand is that while the arity is not a part of it, whether > the given type is opaque or not is, so you can have both `-type t()` and `-opaque t()`. > > So I have two questions: > > - Is being unable to have both type value/0 and value/1 a bug? > - Does being able to have both type t opaque and non-opaque have any purpose? Hi Antony, We are aware of these issues and we are in the process of fixing them. Unfortunately, they require major surgery... Sort answers to your questions: 1. No -- just a current limitation that will be lifted soon, I hope. 2. No -- it should be prohibited by erl_lint already; will happen. Kostis From mazen.harake@REDACTED Thu May 26 11:29:20 2011 From: mazen.harake@REDACTED (Mazen Harake) Date: Thu, 26 May 2011 11:29:20 +0200 Subject: [erlang-questions] Erlang/OTP R14B03 has been released In-Reply-To: <4DDD0CCA.7000807@erix.ericsson.se> References: <4DDD0CCA.7000807@erix.ericsson.se> Message-ID: Oh.... :( there it is: RUN_ERL_DISABLE_FLOWCNTRL I tried to stop this truly horrible shortening of the word "CONTROL" but I guess the damage has been done :P Welcoming feature, which shall laugh in our faces every time someone wonders "why isn't it working!?!?" after have misread this as "FLOWCTRL" which would be the more common shortening. well well... "it" happens, I guess :) 2011/5/25 Bj?rn-Egil Dahlberg > > Erlang/OTP R14B03 has been released. > > This release is mainly a stabilization of the R14B03 release (but as usual there are some new functionality as well). > > You can find the README file for the release at > > http://www.erlang.org/download/otp_src_R14B03.readme > > The source distribution and binary distribution for Windows can be downloaded from > > http://www.erlang.org/download/otp_src_R14B03.tar.gz > http://www.erlang.org/download/otp_win32_R14B03.exe > > > Note: To unpack the TAR archive you need a GNU TAR compatible program. > > For installation instructions please read the README file that is part > of the distribution. > > You can also find the source in the official Erlang/OTP git-repository at GitHub (http://github.com/erlang/otp) > > > The on-line documentation can be found at: http://www.erlang.org/doc/ > You can also download the complete HTML documentation or the Unix manual files > > http://www.erlang.org/download/otp_doc_html_R14B03.tar.gz > http://www.erlang.org/download/otp_doc_man_R14B03.tar.gz > > We also want to thank those that sent us patches, suggestions and bug reports. > > The Erlang/OTP Team > Ericsson AB > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From jj@REDACTED Thu May 26 12:17:09 2011 From: jj@REDACTED (Giovanni Giorgi) Date: Thu, 26 May 2011 12:17:09 +0200 (CEST) Subject: [erlang-questions] Web Framework dilemma Message-ID: Hi all, I am new to Erlang. I have studied it on this great book "Erlang Programming A Concurrent Approach to Software Development" http://gioorgi.com/2009/erlang-book/ I am a 12 years java software architect, so I liked a lot the Erlang functional approach because concurrency is an evil beast on java/C++/python/Smalltalk...all languages I have used a bit. Now I'd like to play with some erlang web framework. I have read somethign here I'd like to try a web framework which follows the erlang-way-of-life, which can teach me the erlang programming model. What do you suggest to me? I get a bit stuck on webmachine for lack of examples. Thank you! -- Senior Consultant http://gioorgi.com From watson.timothy@REDACTED Thu May 26 13:07:34 2011 From: watson.timothy@REDACTED (Tim Watson) Date: Thu, 26 May 2011 12:07:34 +0100 Subject: [erlang-questions] Mocking I/O calls - defining sequence of returns In-Reply-To: <4DDD2B5C.4050909@erlang-solutions.com> References: <312F7919-F0D3-4BDB-AA0F-73951D42209A@gmail.com> <4DDB7B44.8030801@erlang-solutions.com> <4DDD2B5C.4050909@erlang-solutions.com> Message-ID: On 25 May 2011 17:16, Adam Lindberg wrote: > I've added something more lightweight to meck's official repo now in version > 0.6 which might solve your problem. See the two commits: > > https://github.com/eproxus/meck/commit/35de01e > https://github.com/eproxus/meck/commit/8d86012 > > It's the functions sequence/4 and loop/4 which works almost the same as > expect/4 except that they return one value at a time from the list given as > input (sequence will exhaust it and stick to the last element, and loop will > loop the results infinitely). > > Cheers, > Adam That's a very nice addition - cheers! From jesper.louis.andersen@REDACTED Thu May 26 13:12:55 2011 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Thu, 26 May 2011 13:12:55 +0200 Subject: [erlang-questions] Web Framework dilemma In-Reply-To: References: Message-ID: On Thu, May 26, 2011 at 12:17, Giovanni Giorgi wrote: > > I'd like to try a web framework which follows the erlang-way-of-life, > which can teach me the erlang programming model. > > What do you suggest to me? > I'd say start by picking the project constraints first and then decide upon what framework/solution to use afterwards. Some frameworks are built upon a Model-View-Controller design whereas others are more like "Here, have an embedded web server. Now you are on your own". What suits you is up to the problem you have. Do you intend to use websockets? Do you intend to generate lots and lots of HTML5? Well there be Javascript in the frontend? What kind of data do you want to store? Some solutions can probably not satisfy all your wants and desires, which will limit the playing field. Personally, I would try to make the project focus on the Erlang part more than the Web part. The Erlang part is what you want to learn after all. This also suggests that using a "raw" webserver will teach you more about Erlang. Some frameworks lure you in with how easy they are, but then again, you are not really programming the language as much as the framework. -- J. From ebegumisa@REDACTED Thu May 26 14:24:38 2011 From: ebegumisa@REDACTED (Edmond Begumisa) Date: Thu, 26 May 2011 22:24:38 +1000 Subject: [erlang-questions] QuickCheck/PropEr In-Reply-To: <70560.1306346074@snookles.snookles.com> References: <70560.1306346074@snookles.snookles.com> Message-ID: Thanks again, You've both been a big help. I now have the starting point I was looking for. - Edmond - On Thu, 26 May 2011 03:54:34 +1000, Scott Lystig Fritchie wrote: > Edmond Begumisa wrote: > > eb> This looks like a good case-study. I will analyse it fully. Quick > eb> one: are there any properties on gen_servers in here? > > Specifically for gen_server, hrm, probably not. But it isn't all that > difficult to do. > > prop_server_doesnt_crash(InitArgs) -> > ?FORALL(Commands, gen_my_servers_commands(), > begin > {ok, Pid} = my_server:start(InitArgs), > [_ = apply(Mod, Func, Args) || {Mod, Fun, Args} <- > Commands], > Result = erlang:is_process_alive(Pid), > catch my_server:please_stop_now(Pid), > Result > end). > > If you want to check if the server is really sane, add a > testing-use-only command to fetch the server's internal state and > replace the last 3 lines with: > > FinalState = my_server:get_internal_state(Pid), > my_server:please_stop_now(Pid), > verify_sanity(FinalState) %% returns boolean() > > The hassle of cleaning up after each test (killing the process under > test) is a pain(*). As Joe Norton pointed out, there's nothing that > prevents you from testing calls directly against your behavior's > callback module, i.e. calling my_server:handle_call/3 directly; you'll > have to do something more fold-like than the simple list-comprehension- > with-apply in the above example, but it's easy enough to do. > > When testing via behavior callback functions, you'll only be testing the > server-side code and not any client-side code (e.g. calculations done > before a gen_server:call(), gen_server:cast(), or '!'). That might be > good, might be not good enough, depends on the purpose of the tests. > > -Scott > > (*) Testing code with any side-effects at all can cause difficulty. In > the example below, just creating a new process is certainly a > side-effect. Many gen_servers register a process name; if your test > framework doesn't clean up those processes 100% correctly(**), then > later tests can fail because a call to erlang:register/2 fails. > > (**) Of course, that's also a problem when using EUnit, or your own test > tools, etc. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From sigmastar@REDACTED Thu May 26 14:33:17 2011 From: sigmastar@REDACTED (Jesse Gumm) Date: Thu, 26 May 2011 07:33:17 -0500 Subject: [erlang-questions] Web Framework dilemma In-Reply-To: Message-ID: <4dde4891.0a14e70a.687d.142e@mx.google.com> My recommendation is to go with Nitrogen: www.nitrogenproject.com The majority of my development these days is in Nitrogen websites. -Jesse -- Jesse Gumm Sigma Star Systems 414.940.4866 On May 26, 2011 5:17 AM, Giovanni Giorgi <jj@REDACTED> wrote: Hi all, I am new to Erlang. I have studied it on this great book "Erlang Programming A Concurrent Approach to Software Development" http://gioorgi.com/2009/erlang-book/ I am a 12 years java software architect, so I liked a lot the Erlang functional approach because concurrency is an evil beast on java/C++/python/Smalltalk...all languages I have used a bit. Now I'd like to play with some erlang web framework. I have read somethign here <http://stackoverflow.com/questions/1794994/considering-an-erlang-web-framework-to-learn-and-use-in-production> I'd like to try a web framework which follows the erlang-way-of-life, which can teach me the erlang programming model. What do you suggest to me? I get a bit stuck on webmachine for lack of examples. Thank you! -- Senior Consultant http://gioorgi.com _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebegumisa@REDACTED Thu May 26 14:34:09 2011 From: ebegumisa@REDACTED (Edmond Begumisa) Date: Thu, 26 May 2011 22:34:09 +1000 Subject: [erlang-questions] Web Framework dilemma In-Reply-To: References: Message-ID: I'd say Yaws. Because it's less focused on the "framework" part and more on programming part, which sounds more like what you need at this point. I personally found doodling a few web-apps with Yaws very educative when I was starting out (which is not so long ago). - Edmond - On Thu, 26 May 2011 20:17:09 +1000, Giovanni Giorgi wrote: > Hi all, > I am new to Erlang. > I have studied it on this great book "Erlang Programming A Concurrent > Approach to Software Development" > http://gioorgi.com/2009/erlang-book/ > > I am a 12 years java software architect, so I liked a lot the Erlang > functional approach because concurrency is an evil beast on > java/C++/python/Smalltalk...all languages I have used a bit. > > Now I'd like to play with some erlang web framework. > I have read somethign here > > > I'd like to try a web framework which follows the erlang-way-of-life, > which can teach me the erlang programming model. > > What do you suggest to me? > > I get a bit stuck on webmachine for lack of examples. > > Thank you! > -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From qwertymaniac@REDACTED Thu May 26 14:52:20 2011 From: qwertymaniac@REDACTED (Harsh J) Date: Thu, 26 May 2011 18:22:20 +0530 Subject: [erlang-questions] Web Framework dilemma In-Reply-To: References: Message-ID: There was a similar thread last month, do read it (starting here): http://erlang.org/pipermail/erlang-questions/2011-April/057711.html On Thu, May 26, 2011 at 3:47 PM, Giovanni Giorgi wrote: > Hi all, > ?I ?am new to Erlang. > I have studied it on this great ?book "Erlang Programming A Concurrent > Approach to Software Development" > ?http://gioorgi.com/2009/erlang-book/ > > I am a 12 years java software architect, so I liked a lot the Erlang > functional approach because concurrency is an evil beast on > java/C++/python/Smalltalk...all languages I have used a bit. > > Now I'd like to play with some erlang web framework. > I have read somethign here > > > I'd like to try a web framework which follows the erlang-way-of-life, > which can teach me the erlang programming model. > > What do you suggest to me? > > I get a bit stuck on webmachine for lack of examples. > > Thank you! > > -- > Senior Consultant > http://gioorgi.com > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Harsh J http://harshj.com From akintayo.segun@REDACTED Thu May 26 15:32:15 2011 From: akintayo.segun@REDACTED (Akintayo A. Olusegun) Date: Thu, 26 May 2011 14:32:15 +0100 Subject: [erlang-questions] Erlang/OTP R14B03 has been released (Mazen Harake) In-Reply-To: References: Message-ID: On May 26, 2011, at 11:00 AM, erlang-questions-request@REDACTED wrote: > Send erlang-questions mailing list submissions to > erlang-questions@REDACTED > > To subscribe or unsubscribe via the World Wide Web, visit > http://erlang.org/mailman/listinfo/erlang-questions > or, via email, send a message with subject or body 'help' to > erlang-questions-request@REDACTED > > You can reach the person managing the list at > erlang-questions-owner@REDACTED > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of erlang-questions digest..." > > > Today's Topics: > > 1. Multiple types with the same name in Dialyzer (Anthony Ramine) > 2. Re: Multiple types with the same name in Dialyzer > (Kostis Sagonas) > 3. Re: Erlang/OTP R14B03 has been released (Mazen Harake) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 26 May 2011 11:24:16 +0200 > From: Anthony Ramine > To: Kostis Sagonas > Cc: Erlang Questions > Subject: [erlang-questions] Multiple types with the same name in > Dialyzer > Message-ID: <96B869B4-4B4A-444F-8294-81C737F61D9B@REDACTED> > Content-Type: text/plain; charset=us-ascii > > Hi, > > I have a type value/1 defined as `-type value(LabelT) :: ...` and I would > like to have a type value/0 with a default LabelT type value like > `-type value() :: value(binary())`. The file compiles just fine but Dialyzer > complains that "Type value is already defined". > > This exception is thrown from dialyzer_utils:add_new_type/6 [1] because the arity > is not a part of a type identity, you can see this in erl_types:type_is_defined/3 [2]. > > What I really don't understand is that while the arity is not a part of it, whether > the given type is opaque or not is, so you can have both `-type t()` and `-opaque t()`. > > So I have two questions: > > - Is being unable to have both type value/0 and value/1 a bug? > - Does being able to have both type t opaque and non-opaque have any purpose? > > Regards, > > [1] https://github.com/erlang/otp/blob/dev/lib/dialyzer/src/dialyzer_utils.erl#L223 > [2] https://github.com/erlang/otp/blob/dev/lib/hipe/cerl/erl_types.erl#L3984 > > -- > Anthony Ramine > Dev:Extend > http://dev-extend.eu > > > > > > > ------------------------------ > > Message: 2 > Date: Thu, 26 May 2011 12:24:58 +0300 > From: Kostis Sagonas > To: Anthony Ramine > Cc: Erlang Questions > Subject: Re: [erlang-questions] Multiple types with the same name in > Dialyzer > Message-ID: <4DDE1C6A.60303@REDACTED> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Anthony Ramine wrote: >> Hi, >> >> I have a type value/1 defined as `-type value(LabelT) :: ...` and I would >> like to have a type value/0 with a default LabelT type value like >> `-type value() :: value(binary())`. The file compiles just fine but Dialyzer >> complains that "Type value is already defined". >> >> This exception is thrown from dialyzer_utils:add_new_type/6 [1] because the arity >> is not a part of a type identity, you can see this in erl_types:type_is_defined/3 [2]. >> >> What I really don't understand is that while the arity is not a part of it, whether >> the given type is opaque or not is, so you can have both `-type t()` and `-opaque t()`. >> >> So I have two questions: >> >> - Is being unable to have both type value/0 and value/1 a bug? >> - Does being able to have both type t opaque and non-opaque have any purpose? > > Hi Antony, > > We are aware of these issues and we are in the process of fixing them. > Unfortunately, they require major surgery... > > Sort answers to your questions: > > 1. No -- just a current limitation that will be lifted soon, I hope. > 2. No -- it should be prohibited by erl_lint already; will happen. > > Kostis > > > ------------------------------ > > Message: 3 > Date: Thu, 26 May 2011 11:29:20 +0200 > From: Mazen Harake > To: "erlang-questions@REDACTED" > Subject: Re: [erlang-questions] Erlang/OTP R14B03 has been released > Message-ID: > Content-Type: text/plain; charset=ISO-8859-1 > > Oh.... :( there it is: > RUN_ERL_DISABLE_FLOWCNTRL > > I tried to stop this truly horrible shortening of the word "CONTROL" > but I guess the damage has been done :P > > Welcoming feature, which shall laugh in our faces every time someone > wonders "why isn't it working!?!?" after have misread this as > "FLOWCTRL" which would be the more common shortening. > > well well... "it" happens, I guess :) > > > > 2011/5/25 Bj?rn-Egil Dahlberg >> >> Erlang/OTP R14B03 has been released. >> >> This release is mainly a stabilization of the R14B03 release (but as usual there are some new functionality as well). >> >> You can find the README file for the release at >> >> http://www.erlang.org/download/otp_src_R14B03.readme >> >> The source distribution and binary distribution for Windows can be downloaded from >> >> http://www.erlang.org/download/otp_src_R14B03.tar.gz >> http://www.erlang.org/download/otp_win32_R14B03.exe >> >> >> Note: To unpack the TAR archive you need a GNU TAR compatible program. >> >> For installation instructions please read the README file that is part >> of the distribution. >> >> You can also find the source in the official Erlang/OTP git-repository at GitHub (http://github.com/erlang/otp) >> >> >> The on-line documentation can be found at: http://www.erlang.org/doc/ >> You can also download the complete HTML documentation or the Unix manual files >> >> http://www.erlang.org/download/otp_doc_html_R14B03.tar.gz >> http://www.erlang.org/download/otp_doc_man_R14B03.tar.gz >> >> We also want to thank those that sent us patches, suggestions and bug reports. >> >> The Erlang/OTP Team >> Ericsson AB >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > > ------------------------------ > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > End of erlang-questions Digest, Vol 10, Issue 43 > ************************************************ p????s ?s??????o ss??un ?un??sn?O ?? o???u??? -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinoski@REDACTED Thu May 26 15:28:16 2011 From: vinoski@REDACTED (Steve Vinoski) Date: Thu, 26 May 2011 09:28:16 -0400 Subject: [erlang-questions] Web Framework dilemma In-Reply-To: References: Message-ID: On Thu, May 26, 2011 at 8:34 AM, Edmond Begumisa wrote: > I'd say Yaws. > > Because it's less focused on the "framework" part and more on programming > part, which sounds more like what you need at this point. I personally found > doodling a few web-apps with Yaws very educative when I was starting out > (which is not so long ago). I agree! :-) And coincidentally, we just released Yaws 1.90 today, see http://yaws.hyber.org for details. A lot of new features, updates, and user contributions. --steve From dmitrii@REDACTED Thu May 26 16:01:59 2011 From: dmitrii@REDACTED (Dmitrii Dimandt) Date: Thu, 26 May 2011 17:01:59 +0300 Subject: [erlang-questions] Web Framework dilemma In-Reply-To: References: Message-ID: <01A746D4-2FC0-46E2-8AAE-433956489434@dmitriid.com> > > I'd like to try a web framework which follows the erlang-way-of-life, > which can teach me the erlang programming model. > > What do you suggest to me? > > I get a bit stuck on webmachine for lack of examples. Well, a web framework might not necessarily teach you Erlang way of life ;) However, there's a nice list of things that each of the current frameworks can do here: http://www.chicagoboss.org/projects/chicagoboss/wiki/Comparison_of_Erlang_Web_Frameworks I believe you can start from this table and chose whichever one you want From kuleshovmail@REDACTED Thu May 26 16:26:11 2011 From: kuleshovmail@REDACTED (Alexander Kuleshov) Date: Thu, 26 May 2011 14:26:11 +0000 Subject: [erlang-questions] Replace list element Message-ID: Hello, How can i fast replace 2 elements in Erlang list? For example I have list: [1,2,3,4], how can i quickly get [1,3,2,4]? Thank you. From comptekki@REDACTED Thu May 26 16:31:28 2011 From: comptekki@REDACTED (Wes James) Date: Thu, 26 May 2011 08:31:28 -0600 Subject: [erlang-questions] Replace list element In-Reply-To: References: Message-ID: One, option: [A,B,C,D] = [1,2,3,4]. E=[A,C,B,D]. -wes On Thu, May 26, 2011 at 8:26 AM, Alexander Kuleshov wrote: > Hello, > > How can i fast replace 2 elements in Erlang list? For example I have > list: [1,2,3,4], how can i quickly get [1,3,2,4]? > > Thank you. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From wsong.cn@REDACTED Thu May 26 16:56:05 2011 From: wsong.cn@REDACTED (Andy W. Song) Date: Thu, 26 May 2011 22:56:05 +0800 Subject: [erlang-questions] Fwd: gen_server and socket In-Reply-To: References: Message-ID: Hi list, Please take a look at this module which implements a WebSocket client. I'm wondering who will call those handle_info() functions. I looked around and can't find a clue. Thanks Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick@REDACTED Thu May 26 17:09:14 2011 From: nick@REDACTED (Niclas Eklund) Date: Thu, 26 May 2011 17:09:14 +0200 Subject: [erlang-questions] detecting ssh auth failures In-Reply-To: References: Message-ID: Hi! I guess that you would prefer to get, for example, an integer or atom as error reason. Correct? I.e. so you could match on the case when you get "Unable to connect using the available authentication methods". In this case the generated message is (the macro represents an integer): #ssh_msg_disconnect{code = ?SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE, description = "Unable to connect using the available" " authentication methods", language = "en"}, But in some cases it contain additional information. E.g. #ssh_msg_disconnect{code = ?SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED, description = "Protocol version " ++ StrVsn ++ " not supported", language = "en"}, In the latter the description reveals more details. Perhaps the error messages could have been a 3 tuple: {error, Code, Description} instead of what's normally used {error, Reason}. Changing the return value would break existing code (applications using SSH), which wouldn't be very popular ;-) Perhaps a configuration parameter could be used to control this (the default behaviour should as it is) .... Best Regards, Niclas @ Erlang/OTP On Tue, 10 May 2011, Daniel Goertzen wrote: > I am using ssh to automatically connect and operate a remote device. I'd > like to distinguish authentication failures from other kinds of failures. > Currently I will get this as an auth failure from ssh:connect(): > > {error,"Unable to connect using the available authentication methods"} > > Now I could include that error string in a pattern to detect an auth > failure, but it feels rather brittle (ie, what if someone changes the > wording). Is there a better way to do it? Is this an API design bug? > > Regards, > Dan. > From spawn.think@REDACTED Thu May 26 17:38:57 2011 From: spawn.think@REDACTED (Ahmed Omar) Date: Thu, 26 May 2011 17:38:57 +0200 Subject: [erlang-questions] Fwd: gen_server and socket In-Reply-To: References: Message-ID: "This function is called by a gen_server when a timeout occurs or when it receives any other message than a synchronous or asynchronous request (or a system message)." http://www.erlang.org/doc/man/gen_server.html#Module:handle_info-2 " A socket in passive mode will return {ok, HttpPacket} from gen_tcp:recv while an active socket will send messages like {http, Socket, HttpPacket}." http://www.erlang.org/doc/man/inet.html#setopts-2 On Thu, May 26, 2011 at 4:56 PM, Andy W. Song wrote: > Hi list, > > Please take a look at this module which > implements a WebSocket client. I'm wondering who will call those > handle_info() functions. I looked around and can't find a clue. > > Thanks > Andy > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think -------------- next part -------------- An HTML attachment was scrubbed... URL: From jj@REDACTED Thu May 26 18:14:20 2011 From: jj@REDACTED (Giovanni Giorgi) Date: Thu, 26 May 2011 18:14:20 +0200 (CEST) Subject: [erlang-questions] Web Framework dilemma In-Reply-To: References: Message-ID: <939b3aeee52a7ddc2208b5ca57d9cd24.squirrel@idisk.gioorgi.com> Hi, first of all, thank to everyone for the prompt response (wow!). About the project constraints: mostly study. I have already done some small erlang stuff, so I'd like to understand "how it is (easy) doing web programming in erlang?" I have a strong web programming background (java struts, jquery stuff, python django, some asp.net webforms, etc). I do not like the Rails-way-of-life, because it is too automatic. On the other end jakarta struts is too boring :) I am trying nitrogen, it is very magic by the way, but it rocks a lot for its own simple design. I will also read the archivced thread suggested! Thank you! On Thu, May 26, 2011 1:12 pm, Jesper Louis Andersen wrote: > On Thu, May 26, 2011 at 12:17, Giovanni Giorgi wrote: >> >> I'd like to try a web framework which follows the erlang-way-of-life, >> which can teach me the erlang programming model. >> >> What do you suggest to me? >> > > I'd say start by picking the project constraints first and then decide > upon what framework/solution to use afterwards. Some frameworks are > built upon a Model-View-Controller design whereas others are more like > "Here, have an embedded web server. Now you are on your own". What > suits you is up to the problem you have. Do you intend to use > websockets? Do you intend to generate lots and lots of HTML5? Well > there be Javascript in the frontend? What kind of data do you want to > store? > > Some solutions can probably not satisfy all your wants and desires, > which will limit the playing field. > > Personally, I would try to make the project focus on the Erlang part > more than the Web part. The Erlang part is what you want to learn > after all. This also suggests that using a "raw" webserver will teach > you more about Erlang. Some frameworks lure you in with how easy they > are, but then again, you are not really programming the language as > much as the framework. > > -- > J. > -- Senior Consultant http://gioorgi.com From mikhail.sobolev@REDACTED Thu May 26 21:15:12 2011 From: mikhail.sobolev@REDACTED (Mikhail Sobolev) Date: Thu, 26 May 2011 22:15:12 +0300 Subject: [erlang-questions] strange behaviour of gb_trees Message-ID: Hi, I played with gb_trees and hit a strange thing: a value that is part of the tree can't be found[1]. Can somebody please point out what I'm doing wrong? -- Misha [1] https://gist.github.com/993823 From gumm@REDACTED Thu May 26 22:46:08 2011 From: gumm@REDACTED (Jesse Gumm) Date: Thu, 26 May 2011 15:46:08 -0500 Subject: [erlang-questions] Web Framework dilemma In-Reply-To: <939b3aeee52a7ddc2208b5ca57d9cd24.squirrel@idisk.gioorgi.com> References: <939b3aeee52a7ddc2208b5ca57d9cd24.squirrel@idisk.gioorgi.com> Message-ID: > I am trying nitrogen, it is very magic by the way, but it rocks a lot > for its own simple design. If you get stuck or run into any issues, be sure to hit up the Nitrogen Mailing List/Google Group. http://groups.google.com/group/nitrogenweb?pli=1 Happy Hacking! -Jesse > > I will also read the archivced thread suggested! > Thank you! > > > On Thu, May 26, 2011 1:12 pm, Jesper Louis Andersen wrote: >> On Thu, May 26, 2011 at 12:17, Giovanni Giorgi wrote: >>> >>> I'd like to try a web framework which follows the erlang-way-of-life, >>> which can teach me the erlang programming model. >>> >>> What do you suggest to me? >>> >> >> I'd say start by picking the project constraints first and then decide >> upon what framework/solution to use afterwards. Some frameworks are >> built upon a Model-View-Controller design whereas others are more like >> "Here, have an embedded web server. Now you are on your own". What >> suits you is up to the problem you have. Do you intend to use >> websockets? Do you intend to generate lots and lots of HTML5? Well >> there be Javascript in the frontend? What kind of data do you want to >> store? >> >> Some solutions can probably not satisfy all your wants and desires, >> which will limit the playing field. >> >> Personally, I would try to make the project focus on the Erlang part >> more than the Web part. The Erlang part is what you want to learn >> after all. This also suggests that using a "raw" webserver will teach >> you more about Erlang. Some frameworks lure you in with how easy they >> are, but then again, you are not really programming the language as >> much as the framework. >> >> -- >> J. >> > > > -- > Senior Consultant > http://gioorgi.com > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Jesse Gumm Sigma Star Systems 414.940.4866 gumm@REDACTED http://www.sigma-star.com From wsong.cn@REDACTED Fri May 27 02:22:15 2011 From: wsong.cn@REDACTED (Andy W. Song) Date: Fri, 27 May 2011 08:22:15 +0800 Subject: [erlang-questions] Fwd: gen_server and socket In-Reply-To: References: Message-ID: Thanks, that explains it. On Thu, May 26, 2011 at 11:38 PM, Ahmed Omar wrote: > "This function is called by a gen_server when a timeout occurs or when it > receives any other message than a synchronous or asynchronous request (or a > system message)." > http://www.erlang.org/doc/man/gen_server.html#Module:handle_info-2 > > " A socket in passive mode will return {ok, HttpPacket} from gen_tcp:recv while > an active socket will send messages like {http, Socket, HttpPacket}." > http://www.erlang.org/doc/man/inet.html#setopts-2 > > On Thu, May 26, 2011 at 4:56 PM, Andy W. Song wrote: > >> Hi list, >> >> Please take a look at this module which >> implements a WebSocket client. I'm wondering who will call those >> handle_info() functions. I looked around and can't find a clue. >> >> Thanks >> Andy >> >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > > > -- > Best Regards, > - Ahmed Omar > http://nl.linkedin.com/in/adiaa > Follow me on twitter > @spawn_think > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Fri May 27 04:08:14 2011 From: ok@REDACTED (Richard O'Keefe) Date: Fri, 27 May 2011 14:08:14 +1200 Subject: [erlang-questions] Replace list element In-Reply-To: References: Message-ID: On 27/05/2011, at 2:26 AM, Alexander Kuleshov wrote: > Hello, > > How can i fast replace 2 elements in Erlang list? For example I have > list: [1,2,3,4], how can i quickly get [1,3,2,4]? First: how do you know which elements to replace? By their value? By their index? By satisfying some property? By some summary of what precedes them? Second: how do you know what to replace them with? Are they fixed values, or are they computed? This may seem silly, but [if is_integer(X), 1 < X, X < 4 -> 5-X ; true -> X end || X <- [1,2,3,4] ] will handle the example you gave, so what is wrong with that answer? From ulf.wiger@REDACTED Fri May 27 08:46:56 2011 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Fri, 27 May 2011 08:46:56 +0200 Subject: [erlang-questions] Replace list element In-Reply-To: References: Message-ID: On 26 May 2011, at 16:26, Alexander Kuleshov wrote: > Hello, > > How can i fast replace 2 elements in Erlang list? For example I have > list: [1,2,3,4], how can i quickly get [1,3,2,4]? From your example, I read the question as "How can I *swap* 2 elements in an Erlang list?" swap([X, Y | T], X, Y) -> [Y, X | T]; swap([H | T], X, Y) -> [H | swap(T, X, Y)]. Decisions to be made include: - swap every instance or just the first pair? - what to do at the end of the list (do we require that there should be at least one matching pair?) I think this is a fairly good example of the kind of operation that, while seemingly generic, is not a particularly good candidate for a library function; it's so easy to implement with the exact semantics you require for your problem, and there *are* possible variants. BR, Ulf W Ulf Wiger, CTO, Erlang Solutions, Ltd. http://erlang-solutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From hd2010@REDACTED Fri May 27 16:25:15 2011 From: hd2010@REDACTED (Henning Diedrich) Date: Fri, 27 May 2011 16:25:15 +0200 Subject: [erlang-questions] Choke Point Message-ID: <4DDFB44B.3090307@eonblast.com> Does the Erlang VM have a choke threshold beyond which performance degrades, similar to the 2GB that the Java VM has/had? [1] I understand Erlang has per process gc and not this gc issue therefore. I am asking not specifically about gc but about any implicit practical limit. Thanks, Henning [1] e.g. see comments http://java.dzone.com/terracotta_java_gc -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.goertzen@REDACTED Fri May 27 16:44:20 2011 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Fri, 27 May 2011 09:44:20 -0500 Subject: [erlang-questions] detecting ssh auth failures In-Reply-To: References: Message-ID: > I guess that you would prefer to get, for example, an integer or atom as > error reason. Correct? That's right. I like the tuple solution because then I wouldn't have to include the record definition. Furthermore, I would prefer an atom instead of a macro for the same reason. > #ssh_msg_disconnect{code = ?SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED, > description = "Protocol version " ++ StrVsn > ++ " not supported", > language = "en"}, This still has some limitations. What if I'm making a GUI app in Spanish and I wanted to display the unsupported version in a dialog box? Something like the following would be more flexible... {error, {ssh_disconnect_protocol_version_not_supported, StrVsn}} ... and more consistent with the way other parts of OTP work (tcp, ssl). But I'm making a mountain out of a molehill. :) I really only need to separate auth errors from other kinds of errors. Any of your ideas would help. Dan. On Thu, May 26, 2011 at 10:09 AM, Niclas Eklund wrote: > > Hi! > > I guess that you would prefer to get, for example, an integer or atom as > error reason. Correct? I.e. so you could match on the case when you get > "Unable to connect using the available authentication methods". In this case > the generated message is (the macro represents an integer): > > #ssh_msg_disconnect{code = ?SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE, > description = "Unable to connect using the available" > " authentication methods", > language = "en"}, > > But in some cases it contain additional information. E.g. > > #ssh_msg_disconnect{code = ?SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED, > description = "Protocol version " ++ StrVsn > ++ " not supported", > language = "en"}, > > In the latter the description reveals more details. Perhaps the error > messages could have been a 3 tuple: > > {error, Code, Description} > > instead of what's normally used {error, Reason}. Changing the return value > would break existing code (applications using SSH), which wouldn't be very > popular ;-) Perhaps a configuration parameter could be used to control this > (the default behaviour should as it is) .... > > Best Regards, > > Niclas @ Erlang/OTP > > > On Tue, 10 May 2011, Daniel Goertzen wrote: > > I am using ssh to automatically connect and operate a remote device. I'd >> like to distinguish authentication failures from other kinds of failures. >> Currently I will get this as an auth failure from ssh:connect(): >> >> {error,"Unable to connect using the available authentication methods"} >> >> Now I could include that error string in a pattern to detect an auth >> failure, but it feels rather brittle (ie, what if someone changes the >> wording). Is there a better way to do it? Is this an API design bug? >> >> Regards, >> Dan. >> >> > > -- Daniel Goertzen ----------------- dang@REDACTED (work) daniel.goertzen@REDACTED (home) ----------------- 1 204 272 6149 (home/office) 1 204 470 8360 (mobile) ----------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From igarai@REDACTED Fri May 27 17:19:16 2011 From: igarai@REDACTED (=?UTF-8?B?ScOxYWtpIEdhcmF5?=) Date: Fri, 27 May 2011 12:19:16 -0300 Subject: [erlang-questions] Choke Point In-Reply-To: <4DDFB44B.3090307@eonblast.com> References: <4DDFB44B.3090307@eonblast.com> Message-ID: On Fri, May 27, 2011 at 11:25, Henning Diedrich wrote: > Does the Erlang VM have a choke threshold beyond which performance degrades, > similar to the 2GB that the Java VM has/had? [1] > > I understand Erlang has per process gc and not this gc issue therefore. I am > asking not specifically about gc but about any implicit practical limit. > > Thanks, > Henning > > [1] e.g. see comments http://java.dzone.com/terracotta_java_gc Most issues are explained here: http://www.erlang.org/doc/efficiency_guide/advanced.html#id68651 I?aki Garay. From nick@REDACTED Fri May 27 17:33:25 2011 From: nick@REDACTED (Niclas Eklund) Date: Fri, 27 May 2011 17:33:25 +0200 Subject: [erlang-questions] detecting ssh auth failures In-Reply-To: References: Message-ID: Hello! Oh sorry, I was probably a little bit vague. The #ssh_msg_disconnect{} record I just included to show how the SSH internally construct a disconnect message and passes it to the other side. I.e. that it can contain other than a fixed description. I guess that this tuple would break less code: {error, {ssh_disconnect_protocol_version_not_supported, Description}} than this one: {error, ssh_disconnect_protocol_version_not_supported, Description} Best Regards, Niclas @ Erlang/OTP On Fri, 27 May 2011, Daniel Goertzen wrote: >> I guess that you would prefer to get, for example, an integer or atom as >> error reason. Correct? > > > That's right. > > I like the tuple solution because then I wouldn't have to include the record > definition. Furthermore, I would prefer an atom instead of a macro for the > same reason. > > > >> #ssh_msg_disconnect{code = ?SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED, >> description = "Protocol version " ++ StrVsn >> ++ " not supported", >> language = "en"}, > > > > This still has some limitations. What if I'm making a GUI app in Spanish > and I wanted to display the unsupported version in a dialog box? Something > like the following would be more flexible... > > {error, {ssh_disconnect_protocol_version_not_supported, StrVsn}} > > ... and more consistent with the way other parts of OTP work (tcp, ssl). > > > But I'm making a mountain out of a molehill. :) I really only need to > separate auth errors from other kinds of errors. Any of your ideas would > help. > > Dan. > > > > On Thu, May 26, 2011 at 10:09 AM, Niclas Eklund wrote: > >> >> Hi! >> >> I guess that you would prefer to get, for example, an integer or atom as >> error reason. Correct? I.e. so you could match on the case when you get >> "Unable to connect using the available authentication methods". In this case >> the generated message is (the macro represents an integer): >> >> #ssh_msg_disconnect{code = ?SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE, >> description = "Unable to connect using the available" >> " authentication methods", >> language = "en"}, >> >> But in some cases it contain additional information. E.g. >> >> #ssh_msg_disconnect{code = ?SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED, >> description = "Protocol version " ++ StrVsn >> ++ " not supported", >> language = "en"}, >> >> In the latter the description reveals more details. Perhaps the error >> messages could have been a 3 tuple: >> >> {error, Code, Description} >> >> instead of what's normally used {error, Reason}. Changing the return value >> would break existing code (applications using SSH), which wouldn't be very >> popular ;-) Perhaps a configuration parameter could be used to control this >> (the default behaviour should as it is) .... >> >> Best Regards, >> >> Niclas @ Erlang/OTP >> >> >> On Tue, 10 May 2011, Daniel Goertzen wrote: >> >> I am using ssh to automatically connect and operate a remote device. I'd >>> like to distinguish authentication failures from other kinds of failures. >>> Currently I will get this as an auth failure from ssh:connect(): >>> >>> {error,"Unable to connect using the available authentication methods"} >>> >>> Now I could include that error string in a pattern to detect an auth >>> failure, but it feels rather brittle (ie, what if someone changes the >>> wording). Is there a better way to do it? Is this an API design bug? >>> >>> Regards, >>> Dan. >>> >>> >> >> > > > -- > Daniel Goertzen > ----------------- > dang@REDACTED (work) > daniel.goertzen@REDACTED (home) > ----------------- > 1 204 272 6149 (home/office) > 1 204 470 8360 (mobile) > ----------------- > From mihai@REDACTED Fri May 27 18:02:20 2011 From: mihai@REDACTED (Mihai Balea) Date: Fri, 27 May 2011 12:02:20 -0400 Subject: [erlang-questions] Choke Point In-Reply-To: <4DDFB44B.3090307@eonblast.com> References: <4DDFB44B.3090307@eonblast.com> Message-ID: On May 27, 2011, at 10:25 AM, Henning Diedrich wrote: > Does the Erlang VM have a choke threshold beyond which performance degrades, similar to the 2GB that the Java VM has/had? [1] > > I understand Erlang has per process gc and not this gc issue therefore. I am asking not specifically about gc but about any implicit practical limit. Not a threshold per se, but you can experience serious performance degradation if messages are allowed to accumulate in a process' mailbox. Typical of a producer/consumer situation, when the consumer can't keep up. Mihai -------------- next part -------------- An HTML attachment was scrubbed... URL: From spawn.think@REDACTED Fri May 27 18:30:36 2011 From: spawn.think@REDACTED (Ahmed Omar) Date: Fri, 27 May 2011 18:30:36 +0200 Subject: [erlang-questions] Process hanging with huge message queue , with current_function, {mnesia_tm, get_dirty_reply, 2} Message-ID: Hi everyone, I have a cluster of nodes, and on some of the nodes i have processes hanging with current_function,{mnesia_tm,get_dirty_reply,2} Checking the code of mnesia_tm:get_dirt_reply/2 , this function will wait forever. It checks every 1 second if the node that is supposed to reply is still a member of running_db_nodes. If yes, it will try to receive either the result, exit message or mnesia down message . And it will keep on doing that forever. So it seems to cover all cases, however the process ends up in an infinite loop. Any ideas? Erlang version : R13B03 on Linux Debian Lenny 5.0.6 -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think -------------- next part -------------- An HTML attachment was scrubbed... URL: From spawn.think@REDACTED Fri May 27 18:49:42 2011 From: spawn.think@REDACTED (Ahmed Omar) Date: Fri, 27 May 2011 18:49:42 +0200 Subject: [erlang-questions] Process hanging with huge message queue , with current_function, {mnesia_tm, get_dirty_reply, 2} In-Reply-To: References: Message-ID: Actually looking into the message queue, the replies are there but they are at the top of list (which is the end of the queue). So i guess the process doesn't have enough time to scan the whole queue to pick up the results. On Fri, May 27, 2011 at 6:30 PM, Ahmed Omar wrote: > Hi everyone, > I have a cluster of nodes, and on some of the nodes i have processes > hanging with current_function,{mnesia_tm,get_dirty_reply,2} > Checking the code of mnesia_tm:get_dirt_reply/2 , this function will wait > forever. It checks every 1 second if the node that is supposed to reply is > still a member of running_db_nodes. If yes, it will try to receive either > the result, exit message or mnesia down message . And it will keep on doing > that forever. > So it seems to cover all cases, however the process ends up in an infinite > loop. > Any ideas? > > Erlang version : R13B03 on Linux Debian Lenny 5.0.6 > > -- > Best Regards, > - Ahmed Omar > http://nl.linkedin.com/in/adiaa > Follow me on twitter > @spawn_think > > -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think -------------- next part -------------- An HTML attachment was scrubbed... URL: From spawn.think@REDACTED Fri May 27 19:02:34 2011 From: spawn.think@REDACTED (Ahmed Omar) Date: Fri, 27 May 2011 19:02:34 +0200 Subject: [erlang-questions] Process hanging with huge message queue , with current_function, {mnesia_tm, get_dirty_reply, 2} In-Reply-To: References: Message-ID: Sorry i expressed it wrong. i mean it's on top of the list, which is the 1st on the front (1st message arrived). but the replies are from only some of the nodes, not all. And get_dirty_reply will wait for a specific node (no matter if replies comes also from other nodes that are involved in the commit) On Fri, May 27, 2011 at 6:49 PM, Ahmed Omar wrote: > Actually looking into the message queue, the replies are there but they are > at the top of list (which is the end of the queue). So i guess the process > doesn't have enough time to scan the whole queue to pick up the results. > > > On Fri, May 27, 2011 at 6:30 PM, Ahmed Omar wrote: > >> Hi everyone, >> I have a cluster of nodes, and on some of the nodes i have processes >> hanging with current_function,{mnesia_tm,get_dirty_reply,2} >> Checking the code of mnesia_tm:get_dirt_reply/2 , this function will wait >> forever. It checks every 1 second if the node that is supposed to reply is >> still a member of running_db_nodes. If yes, it will try to receive either >> the result, exit message or mnesia down message . And it will keep on doing >> that forever. >> So it seems to cover all cases, however the process ends up in an infinite >> loop. >> Any ideas? >> >> Erlang version : R13B03 on Linux Debian Lenny 5.0.6 >> >> -- >> Best Regards, >> - Ahmed Omar >> http://nl.linkedin.com/in/adiaa >> Follow me on twitter >> @spawn_think >> >> > > > -- > Best Regards, > - Ahmed Omar > http://nl.linkedin.com/in/adiaa > Follow me on twitter > @spawn_think > > -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think -------------- next part -------------- An HTML attachment was scrubbed... URL: From watson.timothy@REDACTED Fri May 27 19:25:59 2011 From: watson.timothy@REDACTED (Tim Watson) Date: Fri, 27 May 2011 18:25:59 +0100 Subject: [erlang-questions] Choke Point In-Reply-To: References: <4DDFB44B.3090307@eonblast.com> Message-ID: On 27 May 2011 17:02, Mihai Balea wrote: > > On May 27, 2011, at 10:25 AM, Henning Diedrich wrote: > > Does the Erlang VM have a choke threshold beyond which performance degrades, > similar to the 2GB that the Java VM has/had? [1] > > I understand Erlang has per process gc and not this gc issue therefore. I am > asking not specifically about gc but about any implicit practical limit. > > Not a threshold per se, but you can experience serious performance > degradation if messages are allowed to accumulate in a process' mailbox. > Typical of a producer/consumer situation, when the consumer can't keep up. > Mihai A number of solutions exist to prevent this, including gen_server2 (part of rabbitmq and mirrored as a standalone OTP library on github). I believe the draining of a process' message box prior to handing off to the gen_server callbacks is now (post R13/R14 ?) part of gen_server proper, so as usual the advice is to stick to battle tested OTP behaviours and avoid running into many (though not all) of these kinds of issues. From hd2010@REDACTED Fri May 27 21:26:37 2011 From: hd2010@REDACTED (Henning Diedrich) Date: Fri, 27 May 2011 21:26:37 +0200 Subject: [erlang-questions] Choke Point In-Reply-To: References: <4DDFB44B.3090307@eonblast.com> Message-ID: <4DDFFAED.1070202@eonblast.com> Thank you for your responses, looking specifically at scaling hardware: is there an implicit, or, practical limit that is experienced, of useful numbers of cores as it stands now? Or is the promise of scale across ever more numbers of cores, almost transparently, being realized in real world scenarios? And does it look like 128, 256 will make perfect sense and all be put to good use? Same for main memory, are there practical considerations to observe, say beyond 128G, or is the scale going as smooth as once hoped for? Thanks, Henning -------------- next part -------------- An HTML attachment was scrubbed... URL: From moxford@REDACTED Fri May 27 22:34:38 2011 From: moxford@REDACTED (Mike Oxford) Date: Fri, 27 May 2011 13:34:38 -0700 Subject: [erlang-questions] behavior vs behaviour Message-ID: So if you use "behavior" instead of "behaviour" in your behaviour definition, it will compile but you end up with a warning about the behaviour not being found when you actually try to use it. So not quite 1:1 parity; looks like behaviour it is! :) -mox -------------- next part -------------- An HTML attachment was scrubbed... URL: From nico.meyer@REDACTED Sat May 28 00:39:46 2011 From: nico.meyer@REDACTED (Nico Meyer) Date: Sat, 28 May 2011 00:39:46 +0200 Subject: [erlang-questions] strange behaviour of gb_trees In-Reply-To: References: Message-ID: <1306535986.5825.7.camel@monika-laptop> On Thu, 26 May 2011 22:15:12 +0300 Mikhail Sobolev wrote: > Hi, > > I played with gb_trees and hit a strange thing: a value that is part > of the tree can't be found[1]. > > Can somebody please point out what I'm doing wrong? > > -- > Misha > > [1] https://gist.github.com/993823 > > At first glance I would say the argument you provide to gb_trees:from_orddict/1 is not an orddict. And orddict is an ordered list of tuples of size two. Your list is not ordered. Try instead 1> T = gb_trees:from_orddict( lists:sort(P) ). Cheers, Nico From wsong.cn@REDACTED Sat May 28 00:52:49 2011 From: wsong.cn@REDACTED (Andy W. Song) Date: Sat, 28 May 2011 06:52:49 +0800 Subject: [erlang-questions] Question of mailing list subscription Message-ID: Hi, I tried to use email address abcxyz+erlang@REDACTED to subscribe to this mailing list, in order to filter my emails, and succeeded. I could receive messages from the list. But when I post to it, my message just never shows up. I checked the original text of may posting email and found there were two places " Sender" and "Delivered-To" that show my real email address abcxyz@REDACTED which is not the same as what I use to subscribe to the list. I guess this is where the problem from. But this address tag thing is a pretty standard and should work. Could it be mailman is not configured correctly? Thanks Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From moxford@REDACTED Sat May 28 00:55:13 2011 From: moxford@REDACTED (Mike Oxford) Date: Fri, 27 May 2011 15:55:13 -0700 Subject: [erlang-questions] "Calling" question Message-ID: Given a supervisor tree of, say, 5, do call the top level supervisor, which then calls it's next level down "OO style" or do you make calls to lower level supervisors directly? In a larger project with multiple applications, a ...b ......c .........d supervisor:start_child(a) (calls into b, into c, into into d) or supervisor:start_child(d)... What is the canonical "recommended way?" Thanks! -mox -------------- next part -------------- An HTML attachment was scrubbed... URL: From jack@REDACTED Sat May 28 01:04:53 2011 From: jack@REDACTED (Jack Moffitt) Date: Fri, 27 May 2011 17:04:53 -0600 Subject: [erlang-questions] "Calling" question In-Reply-To: References: Message-ID: > supervisor:start_child(a) (calls into b, into c, into into d) > or > supervisor:start_child(d)... The supervisor you make the call to is the one that starts the child and monitors it, so you'll want to pick the supervisor that is directly responsible not the top level one (unless those happen to be one and the same). Generally I had hide calls to supervisor:start_child/2 behind my modules API. For example: sw_bot:create(Config) will call supervisor:start_child(sw_bot_sup, [Config]) (in this case it's a simple_one_for_one supervisor) Now none of my code needs to know who the correct supervisor is except sw_bot. jack. From jack@REDACTED Sat May 28 01:07:15 2011 From: jack@REDACTED (Jack Moffitt) Date: Fri, 27 May 2011 17:07:15 -0600 Subject: [erlang-questions] Question of mailing list subscription In-Reply-To: References: Message-ID: As a workaround you could add that +erlang address as an account you can send mail from in preferences. Then Gmail will pick the correct account for the reply based on the email you are replying to. But the better question is why use +erlang to filter when Gmail can filter very easily on the list headers that are already there? jack. From wsong.cn@REDACTED Sat May 28 01:23:46 2011 From: wsong.cn@REDACTED (Andy W. Song) Date: Sat, 28 May 2011 07:23:46 +0800 Subject: [erlang-questions] Question of mailing list subscription In-Reply-To: References: Message-ID: That's what I did but didn't work. I added +erlang as an account and gmail still sets "Sender" and "Delivered-To" to my real email address. The reason I want this is that: 1. I want to use same email to do different things, such as communicate with friends and subscribe to mailing list. 2. I want to use different display names for different purposes, such as I want to be "Bob" when I am talking to friends and want to be "John" when I post to erlang-questions. 3. Gmail doesn't support multiple display names for same account. I have to add something, like +erlang, to my email address so that Gmail can treat it as a different account. Hope that answers your question. Thanks Andy On Sat, May 28, 2011 at 7:07 AM, Jack Moffitt wrote: > As a workaround you could add that +erlang address as an account you > can send mail from in preferences. Then Gmail will pick the correct > account for the reply based on the email you are replying to. > > But the better question is why use +erlang to filter when Gmail can > filter very easily on the list headers that are already there? > > jack. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikhail.sobolev@REDACTED Sat May 28 05:35:17 2011 From: mikhail.sobolev@REDACTED (Mikhail Sobolev) Date: Sat, 28 May 2011 06:35:17 +0300 Subject: [erlang-questions] strange behaviour of gb_trees In-Reply-To: <1306535986.5825.7.camel@monika-laptop> References: <1306535986.5825.7.camel@monika-laptop> Message-ID: Hi Nico, On 28 May 2011 01:39, Nico Meyer wrote: > At first glance I would say the argument you provide to > gb_trees:from_orddict/1 is not an orddict. And orddict is an ordered > list of tuples of size two. Your list is not ordered. > > Try instead > 1> T = gb_trees:from_orddict( lists:sort(P) ). That was indeed the problem. Thank you very much for spotting it! -- Misha From mabrek@REDACTED Sat May 28 09:17:49 2011 From: mabrek@REDACTED (mabrek) Date: Sat, 28 May 2011 11:17:49 +0400 Subject: [erlang-questions] rebar compile from emacs Message-ID: Hello. There is erlang.el for emacs, it has interactive function called erlang-compile. Is it possible to use it with erlang project that has rebar dependencies and uses .hrl files from deps/*/include? My final goal is to edit erlang module, hit some key sequence and have it compiled and reloaded to some runnning node. Reload is done by distel, but it is unclear how to compile from emacs because because my modules have -include(...) dependencies. Regards, Anton Lebedevich. From moxford@REDACTED Sat May 28 18:39:11 2011 From: moxford@REDACTED (Mike Oxford) Date: Sat, 28 May 2011 09:39:11 -0700 Subject: [erlang-questions] rebar compile from emacs In-Reply-To: References: Message-ID: In your .emacs file, after you include erlang and/or distel, you can change your erlang-compile to execute "rebar compile" or a makefile (rebar compile;rebar generated..) or whatever else you'd like. That will get you past compilation, but I don't know how the reloading works enough post-node-generation. Distel's default compile is C-c-C-k but you can remap that as well if you'd like. Sorry I cannot be of more help but maybe the above will get you rolling a little.. -mox On Sat, May 28, 2011 at 12:17 AM, mabrek wrote: > Hello. > > There is erlang.el for emacs, it has interactive function called > erlang-compile. Is it possible to use it with erlang project that has > rebar dependencies and uses .hrl files from deps/*/include? > My final goal is to edit erlang module, hit some key sequence and have > it compiled and reloaded to some runnning node. > Reload is done by distel, but it is unclear how to compile from emacs > because because my modules have -include(...) dependencies. > > Regards, > Anton Lebedevich. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf.wiger@REDACTED Sat May 28 20:17:13 2011 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Sat, 28 May 2011 20:17:13 +0200 Subject: [erlang-questions] strange behaviour of gb_trees In-Reply-To: <1306535986.5825.7.camel@monika-laptop> References: <1306535986.5825.7.camel@monika-laptop> Message-ID: <38FCC4AF-552F-4F64-ABF3-FC497E9BC74F@erlang-solutions.com> On 28 May 2011, at 00:39, Nico Meyer wrote: > Try instead > 1> T = gb_trees:from_orddict( lists:sort(P) ). To maintain the abstraction, it should be 1> T = gb_trees:from_orddict( orddict:from_list(P) ). Note that orddicts are not just sorted lists - they are sorted {Key, Value} lists where each key occurs at most once. Note also: 2> orddict:from_list([{a,1},{a,2}]). [{a,2}] 3> lists:ukeysort(1,[{a,1},{a,2}]). [{a,1}] Again, stick to the abstraction wherever possible, in order to avoid surprises. BR, Ulf W Ulf Wiger, CTO, Erlang Solutions, Ltd. http://erlang-solutions.com From qqshfox@REDACTED Sat May 28 20:22:34 2011 From: qqshfox@REDACTED (Hanfei Shen) Date: Sun, 29 May 2011 02:22:34 +0800 Subject: [erlang-questions] crypto:mod_exp/3 returns wrong result? Message-ID: Hi all, As the doc says: mod_exp(N, P, M) -> Result Types: N, P, M, Result = Mpint Mpint = binary() This function performs the exponentiation N ^ P mod M, using the crypto library. Now, assume: N = -2, P = 3, M = 3 Then: N ^ P mod M = (-2) ^ 3 mod 3 = (-8) mod 3 = (-3) * 3 + 1 or = (-3) * 2 + (-2) So: the remainder should be 1 or -2 (Remainder, From Wikipedia, http://en.wikipedia.org/wiki/Remainder) But I got a TWO from crypto:mod_exp/3... Is there some wrong...? And I did more tests with erlang, python and ruby. The result: Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:2:2] [rq:2] [async-threads:0] [kernel-poll:false] Eshell V5.8.3 (abort with ^G) 1> crypto:mod_exp(-2, 3, 3). 2 2> crypto:mod_exp(2, 3, 3). 2 3> crypto:mod_exp(-2, 3, -3). 1 4> crypto:mod_exp(2, 3, -3). 8 Python 2.7.1 (r271:86832, Mar 25 2011, 15:07:46) In [1]: pow(-2, 3, 3) Out[1]: 1 In [2]: pow(2, 3, 3) Out[2]: 2 In [3]: pow(-2, 3, -3) Out[3]: -2 In [4]: pow(2, 3, -3) Out[4]: -1 Welcome to IRB. You are using ruby 1.9.2p180 (2011-02-18 revision 30909) [x86_64-linux]. Have fun ;) irb(main):001:0> (-2) ** 3 % 3 1 irb(main):002:0> 2 ** 3 % 3 2 irb(main):003:0> (-2) ** 3 % (-3) -2 irb(main):004:0> 2 ** 3 % (-3) -1 Regards, Hanfei -------------- next part -------------- An HTML attachment was scrubbed... URL: From nico.meyer@REDACTED Sun May 29 10:02:49 2011 From: nico.meyer@REDACTED (Nico Meyer) Date: Sun, 29 May 2011 10:02:49 +0200 Subject: [erlang-questions] strange behaviour of gb_trees In-Reply-To: <38FCC4AF-552F-4F64-ABF3-FC497E9BC74F@erlang-solutions.com> References: <1306535986.5825.7.camel@monika-laptop> <38FCC4AF-552F-4F64-ABF3-FC497E9BC74F@erlang-solutions.com> Message-ID: <4DE1FDA9.2080104@adition.com> This is why weakly typed languages require stronlgy disciplined minds :-). Not sure if the reverse is also true. On 28.05.2011 20:17, Ulf Wiger wrote: > > On 28 May 2011, at 00:39, Nico Meyer wrote: > >> Try instead >> 1> T = gb_trees:from_orddict( lists:sort(P) ). > > To maintain the abstraction, it should be > > 1> T = gb_trees:from_orddict( orddict:from_list(P) ). > > Note that orddicts are not just sorted lists - they are sorted {Key, Value} lists where each key occurs at most once. > > Note also: > > 2> orddict:from_list([{a,1},{a,2}]). > [{a,2}] > 3> lists:ukeysort(1,[{a,1},{a,2}]). > [{a,1}] > > Again, stick to the abstraction wherever possible, in order to avoid surprises. > > BR, > Ulf W > > Ulf Wiger, CTO, Erlang Solutions, Ltd. > http://erlang-solutions.com > > > From ds.erl@REDACTED Sun May 29 13:07:35 2011 From: ds.erl@REDACTED (DS) Date: Sun, 29 May 2011 13:07:35 +0200 Subject: [erlang-questions] Question of mailing list subscription In-Reply-To: References: Message-ID: <2AC461B2-5809-468F-982D-881308D28AAF@sol42.com> On 28 May 2011, at 1:23, Andy W. Song wrote: > 2. I want to use different display names for different purposes, such as I want to be "Bob" when I am talking to friends and want to be "John" when I post to erlang-questions. Expect many difficulties and inconveniences when trying to do this sort of trickery with GMail. I use different names for different purposes; I tried to do it through GMail and finally gave up. GMail not only rewrites the "MAIL FROM:<>" SMTP command, like some (but not all) mail relays do, but also has a bad habit of tampering with "From:" and other mail message headers that IMO should be left alone. It will also reveal your true GMail account name to any recipient. Google's point seems to be that GMail is not and does not want to be a full mail relay. As Mr. Moffitt suggests, you might need to look at more than just the "From:" and/or "To:" headers to correctly filter your incoming mail. Regards. -Daniel From ulf.wiger@REDACTED Sun May 29 14:00:50 2011 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Sun, 29 May 2011 14:00:50 +0200 Subject: [erlang-questions] strange behaviour of gb_trees In-Reply-To: <4DE1FDA9.2080104@adition.com> References: <1306535986.5825.7.camel@monika-laptop> <38FCC4AF-552F-4F64-ABF3-FC497E9BC74F@erlang-solutions.com> <4DE1FDA9.2080104@adition.com> Message-ID: <215FF7EA-FB9F-4991-9465-D5E35EB46363@erlang-solutions.com> On 29 May 2011, at 10:02, Nico Meyer wrote: > This is why weakly typed languages require stronlgy disciplined minds :-). Not sure if the reverse is also true. Heh, in this case, I think the discipline required isn't so daunting. The rule of thumb is that you use a module to represent an abstract datatype (in this case, orddict), and then use the API provided rather than trying to glean details about the (usually opaque) data and then assuming that other functions will work just as well. :) I could have added that lists sort will happily sort lists containing objects of any type, whereas ordsets:from_list/1 requires the input to consist of tuples of arity 2, and nothing else. BR, Ulf W > > On 28.05.2011 20:17, Ulf Wiger wrote: >> >> On 28 May 2011, at 00:39, Nico Meyer wrote: >> >>> Try instead >>> 1> T = gb_trees:from_orddict( lists:sort(P) ). >> >> To maintain the abstraction, it should be >> >> 1> T = gb_trees:from_orddict( orddict:from_list(P) ). >> >> Note that orddicts are not just sorted lists - they are sorted {Key, Value} lists where each key occurs at most once. >> >> Note also: >> >> 2> orddict:from_list([{a,1},{a,2}]). >> [{a,2}] >> 3> lists:ukeysort(1,[{a,1},{a,2}]). >> [{a,1}] >> >> Again, stick to the abstraction wherever possible, in order to avoid surprises. >> >> BR, >> Ulf W >> >> Ulf Wiger, CTO, Erlang Solutions, Ltd. >> http://erlang-solutions.com >> >> >> Ulf Wiger, CTO, Erlang Solutions, Ltd. http://erlang-solutions.com From wsong.cn@REDACTED Sun May 29 15:06:52 2011 From: wsong.cn@REDACTED (Andy W. Song) Date: Sun, 29 May 2011 21:06:52 +0800 Subject: [erlang-questions] Question of mailing list subscription In-Reply-To: <2AC461B2-5809-468F-982D-881308D28AAF@sol42.com> References: <2AC461B2-5809-468F-982D-881308D28AAF@sol42.com> Message-ID: Filtering are actually OK because there are alternatives. The real problem is different display names for one gmail address. Now I just use my real gmail address to subscribe to mailing lists and use artificial ones for other purposes. Hope other recipients are OK with it. On Sun, May 29, 2011 at 7:07 PM, DS wrote: > On 28 May 2011, at 1:23, Andy W. Song wrote: > > 2. I want to use different display names for different purposes, such as > I want to be "Bob" when I am talking to friends and want to be "John" when I > post to erlang-questions. > > Expect many difficulties and inconveniences when trying to do this sort of > trickery with GMail. I use different names for different purposes; I tried > to do it through GMail and finally gave up. > > GMail not only rewrites the "MAIL FROM:<>" SMTP command, like some (but not > all) mail relays do, but also has a bad habit of tampering with "From:" and > other mail message headers that IMO should be left alone. It will also > reveal your true GMail account name to any recipient. Google's point seems > to be that GMail is not and does not want to be a full mail relay. > > As Mr. Moffitt suggests, you might need to look at more than just the > "From:" and/or "To:" headers to correctly filter your incoming mail. > > Regards. > -Daniel > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wsongcn@REDACTED Sun May 29 15:59:11 2011 From: wsongcn@REDACTED (Andy W. Song) Date: Sun, 29 May 2011 21:59:11 +0800 Subject: [erlang-questions] Cowboy vs Misultin Message-ID: Hi, I want to build a C1000K test and see how Erlang performs. Here is the start: Cowboy vs Misultin on WebSocket. Both of them support WebSocket out of box. I use code examples from here and here . Both are very simple echo servers. I added erlang:hibernate/3 call into to both Cowboy and Misultin's WebSocket handler loop to save memory. The client code is attached which I modified from this one. It's a quick hack with a fixed request and doesn't really do the handshake. run the client by 'sample_client:start(A,B,C)'. A - number of local IP address you want to use. B - number of connections per IP C - base port number per IP. I started with A=20, B=10000 because I don't have that much of memory. What I found: 1. with 200K connections, my client's Erlang instance takes about 2.2G residence memory, about the same for Cowboy and 3.8G for Misultin. 2. When number of connections is higher than 30K, Cowboy's CPU usage is going up and I start to see gen_tcp:connect times out. Misultin's CPU usage is pretty consistent and doesn't cause client time out. Cowboy's code is simpler and it only uses one process per WebSocket connection. I really like to find out why its CPU load is high. I'm new to Erlang and don't really know how. Erlang manual mentions about etop, but my installation on Linux doesn't have that etop script. I do find that etop module has a start/1 function but I don't know what I should input for the parameter. The Erlang menu doesn't say a word about this function. Thanks Andy -- --------------------------------------------------------------- ???????????????????? ???????????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: websocket_client2.erl Type: text/x-erlang Size: 6177 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sample_client.erl Type: text/x-erlang Size: 1114 bytes Desc: not available URL: From essen@REDACTED Sun May 29 16:26:34 2011 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Sun, 29 May 2011 16:26:34 +0200 Subject: [erlang-questions] Cowboy vs Misultin In-Reply-To: References: Message-ID: <4DE2579A.70000@dev-extend.eu> Hello, Main author of cowboy here. I've been assisting other people in performing websocket tests, and so far all the results have been very similar. > I added erlang:hibernate/3 call into to both Cowboy > and Misultin's WebSocket handler loop to save memory. Good point, we were planning to add a hibernate option as a handler return value like gen_server and friends are doing. > 1. with 200K connections, my client's Erlang instance takes about 2.2G > residence memory, about the same for Cowboy and 3.8G for Misultin. That's good to know. I wasn't expecting such a difference so it's a good surprise. :) > 2. When number of connections is higher than 30K, Cowboy's CPU usage is > going up and I start to see gen_tcp:connect times out. Misultin's CPU > usage is pretty consistent and doesn't cause client time out. CPU usage in cowboy's websockets isn't that great yet. That's partly because we haven't performed any optimization of the websocket code yet. Friday we were talking about it and I've identified a couple things to try to improve it. We were planning to test on monday. If you want you can try them out. Everything is in cowboy_http_websocket. There is: * L139: binary:match is probably too expensive to simply find byte 255. * L176: we are constructing a new binary that copies the message to send because of the prepending. We should instead use an iolist(): Transport:send(Socket, [0, Data, 255]). That's it for now without actually testing. The second one is probably the main culprit. We'll be looking more into it tomorrow, you can find us on #erlounge or #erlang on freenode to follow advancement. Thanks. -- Lo?c Hoguin Dev:Extend From roberto@REDACTED Sun May 29 16:38:30 2011 From: roberto@REDACTED (Roberto Ostinelli) Date: Sun, 29 May 2011 16:38:30 +0200 Subject: [erlang-questions] Cowboy vs Misultin In-Reply-To: References: Message-ID: 2011/5/29 Andy W. Song > Hi, > > I want to build a C1000K test and see how Erlang performs. > > Here is the start: Cowboy vs Misultin on WebSocket. > Both of them support WebSocket out of box. I use code examples from here and > here . Both are > very simple echo servers. I added erlang:hibernate/3 call into to both > Cowboy and Misultin's WebSocket handler loop to save memory. > > The client code is attached which I modified from this one. > It's a quick hack with a fixed request and doesn't really do the handshake. > run the client by 'sample_client:start(A,B,C)'. > A - number of local IP address you want to use. > B - number of connections per IP > C - base port number per IP. > I started with A=20, B=10000 because I don't have that much of memory. > > What I found: > 1. with 200K connections, my client's Erlang instance takes about 2.2G > residence memory, about the same for Cowboy and 3.8G for Misultin. > 2. When number of connections is higher than 30K, Cowboy's CPU usage is > going up and I start to see gen_tcp:connect times out. Misultin's CPU usage > is pretty consistent and doesn't cause client time out. > please provide complete code to reproduce these tests, environment specifications, and configuration settings. i don't see why misultin's memory usage should have this much difference and would like to understand better. i'm currently keeping two distinct ets tables for open tcp connections and open websocket ones, so that could be a spot but is currently the only one which i can think of. very good to see that misultin is being CPU consistent all the way through and not timing out on new connections. r. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tristan.sloughter@REDACTED Sun May 29 23:01:41 2011 From: tristan.sloughter@REDACTED (Tristan Sloughter) Date: Sun, 29 May 2011 16:01:41 -0500 Subject: [erlang-questions] Webmachine pass-off to Misultin/Cowboy Message-ID: I was curious if anyone has used Misultin or Cowboy in someway with Webmachine to handle websockets? My thinking is Webmachine handles everything but when an upgrade request is received it passes off the socket to Misultin or Cowboy. I ask this since websockets don't exactly fit the Webmachine way of doing things but it would be nice to use Webmachine for everything else. Which was also expressed by everyone on the webmachine mailing list when I asked about use of websockets in Webmachine. But maybe I'm going about this all wrong... Tristan -------------- next part -------------- An HTML attachment was scrubbed... URL: From kennethstone@REDACTED Sun May 29 23:24:29 2011 From: kennethstone@REDACTED (Kenny Stone) Date: Sun, 29 May 2011 16:24:29 -0500 Subject: [erlang-questions] Webmachine pass-off to Misultin/Cowboy In-Reply-To: References: Message-ID: Nitrogen could be a solution. Nitrogen supports webmachine as a backend and comet for push messaging to the client. No websockets, though the advantages of websockets over comet is probably only seen when you need high throughput... I asked the nitrogen list about using it for push messaging behind a rails app but didn't get a response. On Sun, May 29, 2011 at 4:01 PM, Tristan Sloughter < tristan.sloughter@REDACTED> wrote: > I was curious if anyone has used Misultin or Cowboy in someway with > Webmachine to handle websockets? My thinking is Webmachine handles > everything but when an upgrade request is received it passes off the socket > to Misultin or Cowboy. > > I ask this since websockets don't exactly fit the Webmachine way of doing > things but it would be nice to use Webmachine for everything else. Which was > also expressed by everyone on the webmachine mailing list when I asked about > use of websockets in Webmachine. > > But maybe I'm going about this all wrong... > > Tristan > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinoski@REDACTED Sun May 29 23:51:58 2011 From: vinoski@REDACTED (Steve Vinoski) Date: Sun, 29 May 2011 17:51:58 -0400 Subject: [erlang-questions] Webmachine pass-off to Misultin/Cowboy In-Reply-To: References: Message-ID: On Sun, May 29, 2011 at 5:01 PM, Tristan Sloughter wrote: > I was curious if anyone has used Misultin or Cowboy in someway with > Webmachine to handle websockets? My thinking is Webmachine handles > everything but when an upgrade request is received it passes off the socket > to Misultin or Cowboy. You could always port webmachine to Yaws, which has supported websockets for quite awhile now. But I thought Kevin Smith has already done something with webmachine and websockets? https://github.com/kevsmith/webmachine > I ask this since websockets don't exactly fit the Webmachine way of doing > things but it would be nice to use Webmachine for everything else. Which was > also expressed by everyone on the webmachine mailing list when I asked about > use of websockets in Webmachine. Correct, since webmachine is all about following the rules of HTTP while websockets is a way of stepping outside of HTTP. > But maybe I'm going about this all wrong... Maybe so; it depends on why stepping outside of HTTP seems advantageous. --steve From tristan.sloughter@REDACTED Mon May 30 00:01:42 2011 From: tristan.sloughter@REDACTED (Tristan Sloughter) Date: Sun, 29 May 2011 17:01:42 -0500 Subject: [erlang-questions] Webmachine pass-off to Misultin/Cowboy In-Reply-To: References: Message-ID: Kevin Smith simply includes a version of mochiweb that supports websockets. At least from what I could tell of that repo when I looked at it before. And the reason I don't want to use comet and why its "advantageous" is simply curiosity and fun :). Tristan On Sun, May 29, 2011 at 4:51 PM, Steve Vinoski wrote: > On Sun, May 29, 2011 at 5:01 PM, Tristan Sloughter > wrote: > > I was curious if anyone has used Misultin or Cowboy in someway with > > Webmachine to handle websockets? My thinking is Webmachine handles > > everything but when an upgrade request is received it passes off the > socket > > to Misultin or Cowboy. > > You could always port webmachine to Yaws, which has supported > websockets for quite awhile now. But I thought Kevin Smith has already > done something with webmachine and websockets? > > https://github.com/kevsmith/webmachine > > > I ask this since websockets don't exactly fit the Webmachine way of doing > > things but it would be nice to use Webmachine for everything else. Which > was > > also expressed by everyone on the webmachine mailing list when I asked > about > > use of websockets in Webmachine. > > Correct, since webmachine is all about following the rules of HTTP > while websockets is a way of stepping outside of HTTP. > > > But maybe I'm going about this all wrong... > > Maybe so; it depends on why stepping outside of HTTP seems advantageous. > > --steve > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wsongcn@REDACTED Mon May 30 02:05:30 2011 From: wsongcn@REDACTED (Andy W. Song) Date: Mon, 30 May 2011 08:05:30 +0800 Subject: [erlang-questions] Cowboy vs Misultin In-Reply-To: References: Message-ID: I cloned Misultin from GitHub, the latest commit is: commit 1ab74e3ae1d6c41f8486f798e6ff43b011e2fd97 Author: Roberto Ostinelli Date: Sat Apr 23 17:33:13 2011 -0700 removed unnecessary code. Both Cowboy and Cowboy examples are cloned from GitHub. The last commit to Cowboy is: commit 5d698250b228229001ca9966a390bf1545fcd0b0 Author: Lo?c Hoguin Date: Mon May 9 22:01:31 2011 +0200 My change is attached. Configuration: Machine 1: run Cowboy or Misultin, ip address 30.0.1.1 Machine 2: run client code, ip address 30.0.1.X, X=2~50, config it by "for ((x=2; x<50; x++)); do ip addr add 30.0.1.$x/24 dev eth0; done" My machine info(Both machines are identical VMware VMs): Debian GNU/Linux 6.0.1 (squeeze) 2.6.32-5-amd64 Erlang R14A (erts-5.8). A little more about Misultin, when it's running, each Websocket connect maps to two processes: <0.632.0> erlang:apply/2 343 50 0 erlang:hibernate/3 0 <0.633.0> erlang:apply/2 18 1410 0 erlang:hibernate/3 0 The second one is the one with TCP link. Thanks Andy On Sun, May 29, 2011 at 10:38 PM, Roberto Ostinelli wrote: > 2011/5/29 Andy W. Song > > Hi, >> >> I want to build a C1000K test and see how Erlang performs. >> >> Here is the start: Cowboy vs Misultin on WebSocket. >> Both of them support WebSocket out of box. I use code examples from here and >> here . Both are >> very simple echo servers. I added erlang:hibernate/3 call into to both >> Cowboy and Misultin's WebSocket handler loop to save memory. >> >> The client code is attached which I modified from this one. >> It's a quick hack with a fixed request and doesn't really do the handshake. >> run the client by 'sample_client:start(A,B,C)'. >> A - number of local IP address you want to use. >> B - number of connections per IP >> C - base port number per IP. >> I started with A=20, B=10000 because I don't have that much of memory. >> >> What I found: >> 1. with 200K connections, my client's Erlang instance takes about 2.2G >> residence memory, about the same for Cowboy and 3.8G for Misultin. >> 2. When number of connections is higher than 30K, Cowboy's CPU usage is >> going up and I start to see gen_tcp:connect times out. Misultin's CPU usage >> is pretty consistent and doesn't cause client time out. >> > > > please provide complete code to reproduce these tests, environment > specifications, and configuration settings. i don't see why misultin's > memory usage should have this much difference and would like to understand > better. i'm currently keeping two distinct ets tables for open tcp > connections and open websocket ones, so that could be a spot but is > currently the only one which i can think of. > > very good to see that misultin is being CPU consistent all the way through > and not timing out on new connections. > > r. > -- --------------------------------------------------------------- ???????????????????? ???????????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: misultin.diff Type: text/x-patch Size: 4947 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cowboy.diff Type: text/x-patch Size: 3501 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cowboy_examples.diff Type: text/x-patch Size: 1699 bytes Desc: not available URL: From jesper.pettersson@REDACTED Mon May 30 08:39:59 2011 From: jesper.pettersson@REDACTED (Jesper Pettersson) Date: Mon, 30 May 2011 08:39:59 +0200 Subject: [erlang-questions] crypto:mod_exp/3 returns wrong result? In-Reply-To: References: Message-ID: Writing a small example in C using the bignum library in openssl (used by the Erlang crypto driver) shows that the result there is 1 as well. #include #include #include int main(int argc, char *argv[]) { static const char b[] = "-2"; static const char e[] = "3"; static const char m[] = "3"; BIGNUM *bnb = NULL; BIGNUM *bne = NULL; BIGNUM *bnm = NULL; BIGNUM *res = BN_new(); BN_CTX *ctx = BN_CTX_new(); BN_dec2bn(&bnb, b); /* convert the string to BIGNUM */ BN_dec2bn(&bne, e); BN_dec2bn(&bnm, m); BN_mod_exp(res, bnb, bne, bnm, ctx); char *result_str = BN_bn2dec(res); /* convert the res BIGNUM to string */ printf("%s\n", result_str); OPENSSL_free(result_str); BN_free(bnb); BN_free(bne); BN_free(bnm); BN_CTX_free(ctx); return 0; } $ gcc -o bn -lcrypto bn.c $ ./bn 1 /Jesper Pettersson Klarna AB On Sat, May 28, 2011 at 8:22 PM, Hanfei Shen wrote: > Hi all, > > As the doc says: > > mod_exp(N, P, M) -> Result > > Types: > N, P, M, Result = Mpint > Mpint = binary() > > This function performs the exponentiation N ^ P mod M, using the crypto > library. > > Now, assume: N = -2, P = 3, M = 3 > Then: N ^ P mod M = (-2) ^ 3 mod 3 > = (-8) mod 3 > = (-3) * 3 + 1 > or = (-3) * 2 + (-2) > So: the remainder should be 1 or -2 > (Remainder, From Wikipedia, http://en.wikipedia.org/wiki/Remainder) > > But I got a TWO from crypto:mod_exp/3... Is there some wrong...? > And I did more tests with erlang, python and ruby. > The result: > > Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:2:2] [rq:2] > [async-threads:0] [kernel-poll:false] > > Eshell V5.8.3 (abort with ^G) > 1> crypto:mod_exp(-2, 3, 3). > 2 > 2> crypto:mod_exp(2, 3, 3). > 2 > 3> crypto:mod_exp(-2, 3, -3). > 1 > 4> crypto:mod_exp(2, 3, -3). > 8 > > Python 2.7.1 (r271:86832, Mar 25 2011, 15:07:46) > > In [1]: pow(-2, 3, 3) > Out[1]: 1 > > In [2]: pow(2, 3, 3) > Out[2]: 2 > > In [3]: pow(-2, 3, -3) > Out[3]: -2 > > In [4]: pow(2, 3, -3) > Out[4]: -1 > > Welcome to IRB. You are using ruby 1.9.2p180 (2011-02-18 revision 30909) > [x86_64-linux]. Have fun ;) > irb(main):001:0> (-2) ** 3 % 3 > 1 > irb(main):002:0> 2 ** 3 % 3 > 2 > irb(main):003:0> (-2) ** 3 % (-3) > -2 > irb(main):004:0> 2 ** 3 % (-3) > -1 > > > Regards, > Hanfei > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- Jesper Pettersson Klarna AB Norra Stationsgatan 61 113 43 Stockholm, Sweden Tel: +46 8 - 120 120 00 Mob: +46 70 - 001 27 25 Fax: +46 8 - 120 120 99 E-mail: jesper.pettersson@REDACTED Web: www.klarna.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto@REDACTED Mon May 30 09:58:55 2011 From: roberto@REDACTED (Roberto Ostinelli) Date: Mon, 30 May 2011 09:58:55 +0200 Subject: [erlang-questions] Cowboy vs Misultin In-Reply-To: References: Message-ID: 2011/5/30 Andy W. Song g it by "for ((x=2; x<50; x++)); do ip addr add 30.0.1.$x/24 dev eth0; done" > > > My machine info(Both machines are identical VMware VMs): > Debian GNU/Linux 6.0.1 (squeeze) > 2.6.32-5-amd64 > Erlang R14A (erts-5.8). > > Hi Andy, before I go further on this, are you really using R14*A* in your tests? A = beta. One of my client had serious memory leaks when using ejabberd over R14A. All that was required to solve the issue was to upgrade Erlang to a stable release and the memory leaks were gone. Could you please retry these tests on a stable version of Erlang, like R14B03 ? If you are testing memory you'd be better off with a version which is stable in the first place. Thank you, r. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikhail.sobolev@REDACTED Mon May 30 10:52:56 2011 From: mikhail.sobolev@REDACTED (Mikhail Sobolev) Date: Mon, 30 May 2011 11:52:56 +0300 Subject: [erlang-questions] strange behaviour of gb_trees In-Reply-To: <38FCC4AF-552F-4F64-ABF3-FC497E9BC74F@erlang-solutions.com> References: <1306535986.5825.7.camel@monika-laptop> <38FCC4AF-552F-4F64-ABF3-FC497E9BC74F@erlang-solutions.com> Message-ID: Hi Ulf, On 28 May 2011 21:17, Ulf Wiger wrote: > Again, stick to the abstraction wherever possible, in order to avoid surprises. Thank you for the suggestion. -- Misha From essen@REDACTED Mon May 30 11:38:15 2011 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Mon, 30 May 2011 11:38:15 +0200 Subject: [erlang-questions] Cowboy vs Misultin In-Reply-To: References: Message-ID: <4DE36587.8050201@dev-extend.eu> Hi Roberto, On 05/30/2011 09:58 AM, Roberto Ostinelli wrote: > 2011/5/30 Andy W. Song >g > it by "for ((x=2; x<50; x++)); do ip addr add 30.0.1.$x/24 dev eth0; done" > > > My machine info(Both machines are identical VMware VMs): > Debian GNU/Linux 6.0.1 (squeeze) > 2.6.32-5-amd64 > Erlang R14A (erts-5.8). > > > Hi Andy, before I go further on this, are you really using R14*A* in > your tests? A = beta. One of my client had serious memory leaks when > using ejabberd over R14A. All that was required to solve the issue was > to upgrade Erlang to a stable release and the memory leaks were gone. Irregardless of this, AFAIK you are using lists for headers and websocket data. This test doesn't send huge websocket data so it's probably the headers of all the open connections, kept in your websocket loops, that take a lot more space than for cowboy. -- Lo?c Hoguin Dev:Extend From ulf.wiger@REDACTED Mon May 30 11:58:30 2011 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Mon, 30 May 2011 11:58:30 +0200 Subject: [erlang-questions] CSLab, the first 10 years Message-ID: <413169C8-6907-4CF8-82B6-016F8B3EE5EA@erlang-solutions.com> Bjarne D?cker once wrote a nice booklet called "Datalogilaboratoriet - de f?rsta 10 ?ren" (The Computer Science Lab - the first 10 years). http://www.erlang.se/publications/jubileumsskrift.html (unfortunately without the great pictures found in the printed book) I just tried running it through Google Translate http://translate.google.com/translate?js=n&prev=_t&hl=en&ie=UTF-8&layout=2&eotf=1&sl=sv&tl=en&u=http%3A%2F%2Fwww.erlang.se%2Fpublications%2Fjubileumsskrift.html and it works pretty well. Bjarne writes fairly idiomatic Swedish, so the google translator doesn't get too confused*. I think the text is well worth reading, even in this machine-translated form, if you're a sucker for Erlang history. * I did notice this failure: Original: - It's not good enough to have ideas - you must also be able to implement them to know that they work." Translation: - It's not good enough to Have ideas - you must also "request variable to Implement Them to Know That Do They Work." Tip to google: It's not *that* uncommon to find English quotes in Swedish texts. Be prepared for it. BR, Ulf W Ulf Wiger, CTO, Erlang Solutions, Ltd. http://erlang-solutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ferenc.holzhauser@REDACTED Mon May 30 11:59:07 2011 From: ferenc.holzhauser@REDACTED (Ferenc Holzhauser) Date: Mon, 30 May 2011 11:59:07 +0200 Subject: [erlang-questions] Trouble starting mnesia on R14B02/3 node with a R14B01 node connected Message-ID: Hi, After updating Erlang from R14B01 to R14B02 (or B03, tried both) on one node of a 2 node setup I had trouble starting mnesia. Eshell V5.8.3 (abort with ^G) (node2)1> mnesia:start(). =ERROR REPORT==== 26-May-2011::13:54:06 === Mnesia('node2'): ** ERROR ** (core dumped to file: "/home/me/backend/MnesiaCore.node2_1306_410846_451973") ** FATAL ** Failed to merge schema: {aborted, {function_clause, [{mnesia_schema,cs2list, [{cstruct,schema,set,[], ['node2', 'node1'], [],0,read_write,[],[],false,schema, [table,cstruct], [],[], {{1300,896724,827143}, 'node1'}, {{4,0}, {'node2', {1302,780884,609311}}}}]}, {mnesia_schema,do_merge_schema,1}, {mnesia_tm,apply_fun,3}, {mnesia_tm,execute_transaction,5}, {mnesia_schema,schema_coordinator, 3}]}} At the end I stopped both nodes, updated Erlang then I could start both of them. Is it a bug or did I do something wrong when trying to update them one by one? Thanks in advance, Ferenc -------------- next part -------------- An HTML attachment was scrubbed... URL: From wsongcn@REDACTED Mon May 30 12:02:11 2011 From: wsongcn@REDACTED (Andy W. Song) Date: Mon, 30 May 2011 18:02:11 +0800 Subject: [erlang-questions] Cowboy vs Misultin In-Reply-To: References: Message-ID: Version 14.a-dfsg-3 is what comes with Debian stable. It's on my company machine which now doesn't have internet access anymore. Debian splits Erlang to a bunch of small packages. I may download a single Erlang/OTP package and install manually later on. Thanks Andy On Mon, May 30, 2011 at 3:58 PM, Roberto Ostinelli wrote: > 2011/5/30 Andy W. Song g it by "for ((x=2; x<50; x++)); > do ip addr add 30.0.1.$x/24 dev eth0; done" > >> >> My machine info(Both machines are identical VMware VMs): >> Debian GNU/Linux 6.0.1 (squeeze) >> 2.6.32-5-amd64 >> Erlang R14A (erts-5.8). >> >> > Hi Andy, before I go further on this, are you really using R14*A* in your > tests? A = beta. One of my client had serious memory leaks when using > ejabberd over R14A. All that was required to solve the issue was to upgrade > Erlang to a stable release and the memory leaks were gone. > > Could you please retry these tests on a stable version of Erlang, like > R14B03 ? > > If you are testing memory you'd be better off with a version which is > stable in the first place. > > Thank you, > > r. > > -- --------------------------------------------------------------- ???????????????????? ???????????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Mon May 30 12:11:56 2011 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Mon, 30 May 2011 12:11:56 +0200 Subject: [erlang-questions] Cowboy vs Misultin In-Reply-To: References: Message-ID: <4DE36D6C.4050603@dev-extend.eu> On 05/30/2011 12:02 PM, Andy W. Song wrote: > Version 14.a-dfsg-3 is what comes with Debian stable. It's on my company > machine which now doesn't have internet access anymore. > > Debian splits Erlang to a bunch of small packages. I may download a > single Erlang/OTP package and install manually later on. Debian's package should be avoided (same for Ubuntu's and many others). The recommended way to install Erlang is from source. This can be cumbersome though so you might want to try something like kerl to manage your Erlang installation: https://github.com/evax/kerl Also all R*A releases are unstable and should not be used for any serious work. Debian made a very bad choice there by including it in stable instead of an actual stable version. -- Lo?c Hoguin Dev:Extend From sverker@REDACTED Mon May 30 12:17:41 2011 From: sverker@REDACTED (Sverker Eriksson) Date: Mon, 30 May 2011 12:17:41 +0200 Subject: [erlang-questions] crypto:mod_exp/3 returns wrong result? In-Reply-To: References: Message-ID: <4DE36EC5.6090409@erix.ericsson.se> Looks like crypto does not handle negative integers correctly at all. /Sverker, Erlang/OTP Jesper Pettersson wrote: > Writing a small example in C using the bignum library in openssl (used by > the Erlang crypto driver) shows that the result there is 1 as well. > > #include > #include > #include > > int main(int argc, char *argv[]) > { > static const char b[] = "-2"; > static const char e[] = "3"; > static const char m[] = "3"; > > BIGNUM *bnb = NULL; > BIGNUM *bne = NULL; > BIGNUM *bnm = NULL; > BIGNUM *res = BN_new(); > > BN_CTX *ctx = BN_CTX_new(); > > BN_dec2bn(&bnb, b); /* convert the string to BIGNUM */ > BN_dec2bn(&bne, e); > BN_dec2bn(&bnm, m); > > BN_mod_exp(res, bnb, bne, bnm, ctx); > > char *result_str = BN_bn2dec(res); /* convert the res BIGNUM to > string */ > > printf("%s\n", result_str); > > OPENSSL_free(result_str); > > BN_free(bnb); > BN_free(bne); > BN_free(bnm); > BN_CTX_free(ctx); > > return 0; > } > > $ gcc -o bn -lcrypto bn.c > $ ./bn > 1 > > /Jesper Pettersson > Klarna AB > > On Sat, May 28, 2011 at 8:22 PM, Hanfei Shen wrote: > > >> Hi all, >> >> As the doc says: >> >> mod_exp(N, P, M) -> Result >> >> Types: >> N, P, M, Result = Mpint >> Mpint = binary() >> >> This function performs the exponentiation N ^ P mod M, using the crypto >> library. >> >> Now, assume: N = -2, P = 3, M = 3 >> Then: N ^ P mod M = (-2) ^ 3 mod 3 >> = (-8) mod 3 >> = (-3) * 3 + 1 >> or = (-3) * 2 + (-2) >> So: the remainder should be 1 or -2 >> (Remainder, From Wikipedia, http://en.wikipedia.org/wiki/Remainder) >> >> But I got a TWO from crypto:mod_exp/3... Is there some wrong...? >> And I did more tests with erlang, python and ruby. >> The result: >> >> Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:2:2] [rq:2] >> [async-threads:0] [kernel-poll:false] >> >> Eshell V5.8.3 (abort with ^G) >> 1> crypto:mod_exp(-2, 3, 3). >> 2 >> 2> crypto:mod_exp(2, 3, 3). >> 2 >> 3> crypto:mod_exp(-2, 3, -3). >> 1 >> 4> crypto:mod_exp(2, 3, -3). >> 8 >> >> Python 2.7.1 (r271:86832, Mar 25 2011, 15:07:46) >> >> In [1]: pow(-2, 3, 3) >> Out[1]: 1 >> >> In [2]: pow(2, 3, 3) >> Out[2]: 2 >> >> In [3]: pow(-2, 3, -3) >> Out[3]: -2 >> >> In [4]: pow(2, 3, -3) >> Out[4]: -1 >> >> Welcome to IRB. You are using ruby 1.9.2p180 (2011-02-18 revision 30909) >> [x86_64-linux]. Have fun ;) >> irb(main):001:0> (-2) ** 3 % 3 >> 1 >> irb(main):002:0> 2 ** 3 % 3 >> 2 >> irb(main):003:0> (-2) ** 3 % (-3) >> -2 >> irb(main):004:0> 2 ** 3 % (-3) >> -1 >> >> >> Regards, >> Hanfei >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> > > > > ------------------------------------------------------------------------ > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From roberto@REDACTED Mon May 30 12:30:54 2011 From: roberto@REDACTED (Roberto Ostinelli) Date: Mon, 30 May 2011 12:30:54 +0200 Subject: [erlang-questions] Cowboy vs Misultin In-Reply-To: <4DE36587.8050201@dev-extend.eu> References: <4DE36587.8050201@dev-extend.eu> Message-ID: 2011/5/30 Lo?c Hoguin > Hi Roberto, > > Irregardless of this, AFAIK you are using lists for headers and > websocket data. This test doesn't send huge websocket data so it's > probably the headers of all the open connections, kept in your websocket > loops, that take a lot more space than for cowboy. > hi loic, side note first: this is why i enjoy these tests, they push all of us to do better :) afaik, taken from the efficiency guide: Data type Memory size List 1 word + 1 word per element + the size of each element Binary 3..6 + data (can be shared) so you've probably hit the spot. it's some time now i'm thinking to add the 'binary' option in misultin, this could be the perfect reason to do so. 2011/5/30 Lo?c Hoguin > > Also all R*A releases are unstable and should not be used for any > serious work. Debian made a very bad choice there by including it in > stable instead of an actual stable version. > > couldn't agree more. erlang being packaged as stable in debian was the exact same reason that brought my client to have it installed in her system in the first place. r. -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimo+erlang-questions@REDACTED Mon May 30 14:36:35 2011 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Mon, 30 May 2011 14:36:35 +0200 Subject: [erlang-questions] Question of mailing list subscription In-Reply-To: References: Message-ID: <20110530123635.GA17403@erix.ericsson.se> On Sat, May 28, 2011 at 07:23:46AM +0800, Andy W. Song wrote: > That's what I did but didn't work. I added +erlang as an account and gmail > still sets "Sender" and "Delivered-To" to my real email address. > FYI: Currently, and with the previous mailing list manager (Ezmlm), the only field used when checking if a mail comes from a subscriber is the envelope return path (SMTP MAIL From:) field. It seems to be the most reliable field, partly because it was the only one used by Ezmlm. I and many (38, of which 11 gmail) others are subscribed using this +suffix trick and it works for us. I can see you managed to subscribe your +suffix address and unsubscribed 30 minutes later. Why your post failed is hard to tell afterwards. If I get the msgid I can find that in the logs. You maybe dropped that track a bit early... > The reason I want this is that: > 1. I want to use same email to do different things, such as communicate with > friends and subscribe to mailing list. > 2. I want to use different display names for different purposes, such as I > want to be "Bob" when I am talking to friends and want to be "John" when I > post to erlang-questions. > 3. Gmail doesn't support multiple display names for same account. I have to > add something, like +erlang, to my email address so that Gmail can treat it > as a different account. > > Hope that answers your question. > > Thanks > Andy > > On Sat, May 28, 2011 at 7:07 AM, Jack Moffitt wrote: > > > As a workaround you could add that +erlang address as an account you > > can send mail from in preferences. Then Gmail will pick the correct > > account for the reply based on the email you are replying to. > > > > But the better question is why use +erlang to filter when Gmail can > > filter very easily on the list headers that are already there? > > > > jack. > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From dangud@REDACTED Mon May 30 15:00:12 2011 From: dangud@REDACTED (Dan Gudmundsson) Date: Mon, 30 May 2011 15:00:12 +0200 Subject: [erlang-questions] Trouble starting mnesia on R14B02/3 node with a R14B01 node connected In-Reply-To: References: Message-ID: That is a bug in R14B03, I currently fail to understand how it can go wrong on R14B02.. Did you try R14B03 first? There is a missing make rule, which doesn't trigger a remake if the .hrl file is updated, old clearcase problem which fixed those kind of build dependencies automagicly. /Dan On Mon, May 30, 2011 at 11:59 AM, Ferenc Holzhauser < ferenc.holzhauser@REDACTED> wrote: > Hi, > > After updating Erlang from R14B01 to R14B02 (or B03, tried both) on one > node of a 2 node setup I had trouble starting mnesia. > > Eshell V5.8.3 (abort with > ^G) > > (node2)1> mnesia:start(). > > > =ERROR REPORT==== 26-May-2011::13:54:06 > === > Mnesia('node2'): ** ERROR ** (core dumped to file: > "/home/me/backend/MnesiaCore.node2_1306_410846_451973") > ** FATAL ** Failed to merge schema: > {aborted, > > {function_clause, > > [{mnesia_schema,cs2list, > > [{cstruct,schema,set,[], > ['node2', > 'node1'], > > [],0,read_write,[],[],false,schema, > > [table,cstruct], > > [],[], > > {{1300,896724,827143}, > 'node1'}, > > {{4,0}, > {'node2', > > {1302,780884,609311}}}}]}, > > {mnesia_schema,do_merge_schema,1}, > > {mnesia_tm,apply_fun,3}, > > {mnesia_tm,execute_transaction,5}, > > {mnesia_schema,schema_coordinator, > > 3}]}} > > > > At the end I stopped both nodes, updated Erlang then I could start both of > them. > > Is it a bug or did I do something wrong when trying to update them one by > one? > > Thanks in advance, > Ferenc > > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ferenc.holzhauser@REDACTED Mon May 30 15:17:38 2011 From: ferenc.holzhauser@REDACTED (Ferenc Holzhauser) Date: Mon, 30 May 2011 15:17:38 +0200 Subject: [erlang-questions] Trouble starting mnesia on R14B02/3 node with a R14B01 node connected In-Reply-To: References: Message-ID: Yes, I did try R14B03 first then R14B02 to see if that works. BR, Ferenc On 30 May 2011 15:00, Dan Gudmundsson wrote: > That is a bug in R14B03, I currently fail to understand how it can go wrong > on R14B02.. > > Did you try R14B03 first? > There is a missing make rule, which doesn't trigger a remake if the .hrl > file is updated, > old clearcase problem which fixed those kind of build dependencies > automagicly. > > /Dan > > On Mon, May 30, 2011 at 11:59 AM, Ferenc Holzhauser < > ferenc.holzhauser@REDACTED> wrote: > >> Hi, >> >> After updating Erlang from R14B01 to R14B02 (or B03, tried both) on one >> node of a 2 node setup I had trouble starting mnesia. >> >> Eshell V5.8.3 (abort with >> ^G) >> >> (node2)1> mnesia:start(). >> >> >> =ERROR REPORT==== 26-May-2011::13:54:06 >> === >> Mnesia('node2'): ** ERROR ** (core dumped to file: >> "/home/me/backend/MnesiaCore.node2_1306_410846_451973") >> ** FATAL ** Failed to merge schema: >> {aborted, >> >> {function_clause, >> >> [{mnesia_schema,cs2list, >> >> [{cstruct,schema,set,[], >> ['node2', >> 'node1'], >> >> [],0,read_write,[],[],false,schema, >> >> [table,cstruct], >> >> [],[], >> >> {{1300,896724,827143}, >> 'node1'}, >> >> {{4,0}, >> {'node2', >> >> {1302,780884,609311}}}}]}, >> >> {mnesia_schema,do_merge_schema,1}, >> >> {mnesia_tm,apply_fun,3}, >> >> {mnesia_tm,execute_transaction,5}, >> >> {mnesia_schema,schema_coordinator, >> >> 3}]}} >> >> >> >> At the end I stopped both nodes, updated Erlang then I could start both of >> them. >> >> Is it a bug or did I do something wrong when trying to update them one by >> one? >> >> Thanks in advance, >> Ferenc >> >> >> >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto@REDACTED Mon May 30 16:20:08 2011 From: roberto@REDACTED (Roberto Ostinelli) Date: Mon, 30 May 2011 16:20:08 +0200 Subject: [erlang-questions] Cowboy vs Misultin In-Reply-To: References: Message-ID: 2011/5/30 Andy W. Song > Version 14.a-dfsg-3 is what comes with Debian stable. It's on my company > machine which now doesn't have internet access anymore. > > Debian splits Erlang to a bunch of small packages. I may download a single > Erlang/OTP package and install manually later on. > > Thanks > Andy > misultin has just been updated in the master branch [0.8-dev] to support binary mode. i would be very interested if you could redo your tests using the binary example for websockets: https://github.com/ostinelli/misultin/blob/master/examples/misultin_websocket_binary_example.erl let's see if loic hit the spot :) r. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanitous@REDACTED Mon May 30 20:17:22 2011 From: nanitous@REDACTED (Nanitous) Date: Mon, 30 May 2011 20:17:22 +0200 Subject: [erlang-questions] crypto:mod_exp/3 returns wrong result? In-Reply-To: References: Message-ID: <5D91FB84-56F8-4E88-AC1D-A749902BE56D@xs4all.nl> Hi Jesper, Hanfei, For the purpose in cryptographical applications this is not a problem, where in practivce only positive number are considered (actually elements from a group Z_p). Of course one can debate whether Erlang should faithfully conserve the negative sign between libraries. But, as said before, for the crypto applications of mod_exp, it doesn't matter. kr Twan. I went into the source code (see below) and the following happens: 0. The OpenSSL Big Number representation is a structure in which whether a number is negative is a separate flag in the structure: struct bignum_st { BN_ULONG *d; /* Pointer to an array of 'BN_BITS2' bit chunks. */ int top; /* Index of last used d +1. */ /* The next are internal book keeping for bn_expand. */ int dmax; /* Size of the d array. */ int neg; /* one if the number is negative */ int flags; }; typedef struct bignum_st BIGNUM; From the openSSL bn.h: /** BN_set_negative sets sign of a BIGNUM * \param b pointer to the BIGNUM object * \param n 0 if the BIGNUM b should be positive and a value != 0 otherwise */ void BN_set_negative(BIGNUM *b, int n); /** BN_is_negative returns 1 if the BIGNUM is negative * \param a pointer to the BIGNUM object * \return 1 if a < 0 and 0 otherwise */ #define BN_is_negative(a) ((a)->neg != 0) 1. The conversion of Erlang "big number" to openSSL "big numbers" ignores whether the binary big number representation of Erlang signifies a negative number: static int get_bn_from_mpint(ErlNifEnv* env, ERL_NIF_TERM term, BIGNUM** bnp) { ErlNifBinary bin; int sz; if (!enif_inspect_binary(env,term,&bin)) { return 0; } ERL_VALGRIND_ASSERT_MEM_DEFINED(bin.data, bin.size); sz = bin.size - 4; if (sz < 0 || get_int32(bin.data) != sz) { return 0; } *bnp = BN_bin2bn(bin.data+4, sz, NULL); return 1; } 2. The reverse conversion when the openSSL function BN_mod_exp has computed its result, the conversion from the openSSL representation to the Erlang representation ignores again any negative results. From Erlang: crypto.c static ERL_NIF_TERM mod_exp_nif(ErlNifEnv* env, int argc, const ERL_NIF_TERM argv[]) {/* (Base,Exponent,Modulo) */ BIGNUM *bn_base=NULL, *bn_exponent=NULL, *bn_modulo, *bn_result; BN_CTX *bn_ctx; unsigned char* ptr; unsigned dlen; ERL_NIF_TERM ret; if (!get_bn_from_mpint(env, argv[0], &bn_base) || !get_bn_from_mpint(env, argv[1], &bn_exponent) || !get_bn_from_mpint(env, argv[2], &bn_modulo)) { if (bn_base) BN_free(bn_base); if (bn_exponent) BN_free(bn_exponent); return enif_make_badarg(env); } bn_result = BN_new(); bn_ctx = BN_CTX_new(); BN_mod_exp(bn_result, bn_base, bn_exponent, bn_modulo, bn_ctx); dlen = BN_num_bytes(bn_result); ptr = enif_make_new_binary(env, dlen+4, &ret); put_int32(ptr, dlen); BN_bn2bin(bn_result, ptr+4); BN_free(bn_result); BN_CTX_free(bn_ctx); BN_free(bn_modulo); BN_free(bn_exponent); BN_free(bn_base); return ret; } From: openSSL: bn_lib.h: BIGNUM *BN_bin2bn(const unsigned char *s, int len, BIGNUM *ret) { unsigned int i,m; unsigned int n; BN_ULONG l; BIGNUM *bn = NULL; if (ret == NULL) ret = bn = BN_new(); if (ret == NULL) return(NULL); bn_check_top(ret); l=0; n=len; if (n == 0) { ret->top=0; return(ret); } i=((n-1)/BN_BYTES)+1; m=((n-1)%(BN_BYTES)); if (bn_wexpand(ret, (int)i) == NULL) { if (bn) BN_free(bn); return NULL; } ret->top=i; ret->neg=0; while (n--) { l=(l<<8L)| *(s++); if (m-- == 0) { ret->d[--i]=l; l=0; m=BN_BYTES-1; } } /* need to call this due to clear byte at top if avoiding * having the top bit set (-ve number) */ bn_correct_top(ret); return(ret); } /* ignore negative */ int BN_bn2bin(const BIGNUM *a, unsigned char *to) { int n,i; BN_ULONG l; bn_check_top(a); n=i=BN_num_bytes(a); while (i--) { l=a->d[i/BN_BYTES]; *(to++)=(unsigned char)(l>>(8*(i%BN_BYTES)))&0xff; } return(n); } On 30 mei 2011, at 08:39, Jesper Pettersson wrote: > Writing a small example in C using the bignum library in openssl (used by the Erlang crypto driver) shows that the result there is 1 as well. > > #include > #include > #include > > int main(int argc, char *argv[]) > { > static const char b[] = "-2"; > static const char e[] = "3"; > static const char m[] = "3"; > > BIGNUM *bnb = NULL; > BIGNUM *bne = NULL; > BIGNUM *bnm = NULL; > BIGNUM *res = BN_new(); > > BN_CTX *ctx = BN_CTX_new(); > > BN_dec2bn(&bnb, b); /* convert the string to BIGNUM */ > BN_dec2bn(&bne, e); > BN_dec2bn(&bnm, m); > > BN_mod_exp(res, bnb, bne, bnm, ctx); > > char *result_str = BN_bn2dec(res); /* convert the res BIGNUM to string */ > > printf("%s\n", result_str); > > OPENSSL_free(result_str); > > BN_free(bnb); > BN_free(bne); > BN_free(bnm); > BN_CTX_free(ctx); > > return 0; > } > > $ gcc -o bn -lcrypto bn.c > $ ./bn > 1 > > /Jesper Pettersson > Klarna AB > > On Sat, May 28, 2011 at 8:22 PM, Hanfei Shen wrote: > Hi all, > > As the doc says: > > mod_exp(N, P, M) -> Result > > Types: > N, P, M, Result = Mpint > Mpint = binary() > > This function performs the exponentiation N ^ P mod M, using the crypto library. > > Now, assume: N = -2, P = 3, M = 3 > Then: N ^ P mod M = (-2) ^ 3 mod 3 > = (-8) mod 3 > = (-3) * 3 + 1 > or = (-3) * 2 + (-2) > So: the remainder should be 1 or -2 > (Remainder, From Wikipedia, http://en.wikipedia.org/wiki/Remainder) > > But I got a TWO from crypto:mod_exp/3... Is there some wrong...? > And I did more tests with erlang, python and ruby. > The result: > > Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:2:2] [rq:2] [async-threads:0] [kernel-poll:false] > > Eshell V5.8.3 (abort with ^G) > 1> crypto:mod_exp(-2, 3, 3). > 2 > 2> crypto:mod_exp(2, 3, 3). > 2 > 3> crypto:mod_exp(-2, 3, -3). > 1 > 4> crypto:mod_exp(2, 3, -3). > 8 > > Python 2.7.1 (r271:86832, Mar 25 2011, 15:07:46) > > In [1]: pow(-2, 3, 3) > Out[1]: 1 > > In [2]: pow(2, 3, 3) > Out[2]: 2 > > In [3]: pow(-2, 3, -3) > Out[3]: -2 > > In [4]: pow(2, 3, -3) > Out[4]: -1 > > Welcome to IRB. You are using ruby 1.9.2p180 (2011-02-18 revision 30909) [x86_64-linux]. Have fun ;) > irb(main):001:0> (-2) ** 3 % 3 > 1 > irb(main):002:0> 2 ** 3 % 3 > 2 > irb(main):003:0> (-2) ** 3 % (-3) > -2 > irb(main):004:0> 2 ** 3 % (-3) > -1 > > > Regards, > Hanfei > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > > -- > Jesper Pettersson > > Klarna AB > Norra Stationsgatan 61 > 113 43 Stockholm, Sweden > Tel: +46 8 - 120 120 00 > Mob: +46 70 - 001 27 25 > Fax: +46 8 - 120 120 99 > E-mail: jesper.pettersson@REDACTED > Web: www.klarna.com > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From francis.joanis@REDACTED Mon May 30 20:48:12 2011 From: francis.joanis@REDACTED (Francis Joanis) Date: Mon, 30 May 2011 14:48:12 -0400 Subject: [erlang-questions] Best way to integrate QuickCheck and rebar Message-ID: Hi, I am new to both rebar and QuickCheck and I'm looking for a way to have rebar invoke my QuickCheck tests. The only thing I've found so far is to have an eunit test invoke QuickCheck from within its test. What would be the best way to achieve this? Thanks a lot, Francis -------------- next part -------------- An HTML attachment was scrubbed... URL: From paolo.negri@REDACTED Mon May 30 22:20:42 2011 From: paolo.negri@REDACTED (Paolo Negri) Date: Mon, 30 May 2011 22:20:42 +0200 Subject: [erlang-questions] halfword emulator state Message-ID: Dear list I would like to assess the state of development and recommended usage of the halfword emulator. Apart from the initial announcement [1] and the fixes/improvements introduced with R14B03 [2] there hasn't been much discussion about it. As we're evaluating the use of the halfword emulator in production I would like to ask questions. - Is anyone already using the halfword emulator in production environments, if yes, are what are the experiences, is it stable, what are the effective gains, is there any measurable overhead? - Can the halfword emulator be considered suitable and stable for production usage as the distribution of which is part? - [2] states: "Much more of internal memory structures have been made able to use "high" memory and are no longer restricted to the 4Gb limit that still applies for all process heap data." Is there any documentation explaining exactly which structures can use the high memory and what instead is constrained to the "low" memory? Where would the content of the constant pool reside? - How could the containment of structures restricted to the "low" memory be measured? How would someone monitor the memory usage of the VM being able to prevent out of memory errors without restricting the whole VM to use over 4Gb? - What are the caveats - if any - for using nifs when using the halfword emulator? Which aspects of the nifs should be tested in order to consider safe to run them with the halfword emulator? [1] http://www.erlang.org/download/otp_src_R14B02.readme [2] http://www.erlang.org/download/otp_src_R14B03.readme Thanks for releasing the halfword emulator and thanks in advance for your answers. Paolo From sunwood360@REDACTED Tue May 31 02:49:19 2011 From: sunwood360@REDACTED (envelopes envelopes) Date: Mon, 30 May 2011 17:49:19 -0700 Subject: [erlang-questions] style inconsistency Message-ID: for gen_server.start link , we use {local, Name} for gen_server:cast, we use {Name, Node} I feel the style is inconsistent. one has name before node, one has name after node. what is you opinion? -Sun -------------- next part -------------- An HTML attachment was scrubbed... URL: From mapandfold@REDACTED Tue May 31 03:33:12 2011 From: mapandfold@REDACTED (moi) Date: Mon, 30 May 2011 18:33:12 -0700 (PDT) Subject: [erlang-questions] crypto:mod_exp/3 returns wrong result? In-Reply-To: <5D91FB84-56F8-4E88-AC1D-A749902BE56D@xs4all.nl> References: <5D91FB84-56F8-4E88-AC1D-A749902BE56D@xs4all.nl> Message-ID: <1306805592687-3562121.post@n4.nabble.com> I think the problem with crypto here is if it could not handle negative numbers properly, it should not handle it at all. crypto:mpint/1 is trying to use complement numbers to represent negatives. > crypto:mpint(-1). <<0,0,0,1,255>> > crypto:mod_exp(-2, 3, -3) == crypto:mod_exp(254, 3, 253). true PS, Will Erlang be a possible choice for scientific computation? Like SciPy. -- View this message in context: http://erlang.2086793.n4.nabble.com/crypto-mod-exp-3-returns-wrong-result-tp3557849p3562121.html Sent from the Erlang Questions mailing list archive at Nabble.com. From ok@REDACTED Tue May 31 05:38:57 2011 From: ok@REDACTED (Richard O'Keefe) Date: Tue, 31 May 2011 15:38:57 +1200 Subject: [erlang-questions] halfword emulator state In-Reply-To: References: Message-ID: <75BA56C3-F3C9-435D-AA4A-6B1E2AA3B816@cs.otago.ac.nz> On 31/05/2011, at 8:20 AM, Paolo Negri wrote: > I would like to assess the state of development and recommended usage > of the halfword emulator. Could I just make the point that "halfword" is confusing? I thought it referred to 16-bit units of something. It might be clearer if called the "small pointer emulator" or something like that. From jws@REDACTED Tue May 31 05:46:54 2011 From: jws@REDACTED (Jeff Schultz) Date: Tue, 31 May 2011 13:46:54 +1000 Subject: [erlang-questions] halfword emulator state In-Reply-To: <75BA56C3-F3C9-435D-AA4A-6B1E2AA3B816@cs.otago.ac.nz> References: <75BA56C3-F3C9-435D-AA4A-6B1E2AA3B816@cs.otago.ac.nz> Message-ID: <20110531034654.GA24891@mulga.csse.unimelb.edu.au> On Tue, May 31, 2011 at 03:38:57PM +1200, Richard O'Keefe wrote: > On 31/05/2011, at 8:20 AM, Paolo Negri wrote: > > I would like to assess the state of development and recommended usage > > of the halfword emulator. > Could I just make the point that "halfword" is confusing? > I thought it referred to 16-bit units of something. > It might be clearer if called the "small pointer emulator" > or something like that. Or "compact pointer emulator" or "compact address emulator." Jeff Schultz From overminddl1@REDACTED Tue May 31 07:09:53 2011 From: overminddl1@REDACTED (OvermindDL1) Date: Mon, 30 May 2011 23:09:53 -0600 Subject: [erlang-questions] halfword emulator state In-Reply-To: <20110531034654.GA24891@mulga.csse.unimelb.edu.au> References: <75BA56C3-F3C9-435D-AA4A-6B1E2AA3B816@cs.otago.ac.nz> <20110531034654.GA24891@mulga.csse.unimelb.edu.au> Message-ID: On May 30, 2011 9:47 PM, "Jeff Schultz" wrote: > > On Tue, May 31, 2011 at 03:38:57PM +1200, Richard O'Keefe wrote: > > On 31/05/2011, at 8:20 AM, Paolo Negri wrote: > > > I would like to assess the state of development and recommended usage > > > of the halfword emulator. > > > Could I just make the point that "halfword" is confusing? > > I thought it referred to 16-bit units of something. > > It might be clearer if called the "small pointer emulator" > > or something like that. > > Or "compact pointer emulator" or "compact address emulator." > > > Jeff Schultz Was it not only for 64bit, hence a halfword will only be 32bit, not 16bit? -------------- next part -------------- An HTML attachment was scrubbed... URL: From wsongcn@REDACTED Tue May 31 08:18:05 2011 From: wsongcn@REDACTED (Andy W. Song) Date: Tue, 31 May 2011 14:18:05 +0800 Subject: [erlang-questions] Cowboy vs Misultin In-Reply-To: References: Message-ID: I installed R14B03. I'm disappointed with my Erlang WebSocket client's performance. So I wrote a C version using libev, code attached. Usage: ./new A B C A/B/C have the same meaning of Erlang client. Here is the result with my new client: misultin_websocket_binary_example(file attached, no change to rest of Misultin) start 519M 3.5G CPU, with 550 Kbyte/s traffic about 23%. misultin_websocket_example start 519M 3.5G CPU, with 550 Kbyte/s traffic about 25%. Packet size is 512 bytes, client sends packets, server echo. Cowboy can't pass my test this time. Connections start dropping from 20K, don't know why. Regards Andy On Mon, May 30, 2011 at 10:20 PM, Roberto Ostinelli wrote: > 2011/5/30 Andy W. Song > >> Version 14.a-dfsg-3 is what comes with Debian stable. It's on my company >> machine which now doesn't have internet access anymore. >> >> Debian splits Erlang to a bunch of small packages. I may download a single >> Erlang/OTP package and install manually later on. >> >> Thanks >> Andy >> > > misultin has just been updated in the master branch [0.8-dev] to support > binary mode. > > i would be very interested if you could redo your tests using the binary > example for websockets: > > https://github.com/ostinelli/misultin/blob/master/examples/misultin_websocket_binary_example.erl > > let's see if loic hit the spot :) > > r. > -- --------------------------------------------------------------- ???????????????????? ???????????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile Type: application/octet-stream Size: 59 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test.c Type: text/x-csrc Size: 9207 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: misultin_websocket_binary_example.erl Type: application/octet-stream Size: 3838 bytes Desc: not available URL: From wsongcn@REDACTED Tue May 31 08:32:35 2011 From: wsongcn@REDACTED (Andy W. Song) Date: Tue, 31 May 2011 14:32:35 +0800 Subject: [erlang-questions] Tool for performace evaluation In-Reply-To: <315503444.211231306153617444.JavaMail.root@zimbra> References: <315503444.211231306153617444.JavaMail.root@zimbra> Message-ID: I run Erlang on a remote machine through SSH. When I fire up etop it get: 1> etop:start(). Application initialization failed: no display name and no $DISPLAY environment variable Error in startup script: no display name and no $DISPLAY environment variable while executing "load /usr/lib/libtk8.4.so.0 Tk" ("package ifneeded" script) invoked from within "package require Tk 8.3" (file "/usr/lib/erlang/lib/gs-1.5.12/priv/gstk.tcl" line 7) How can I use text mode? Thanks Andy On Mon, May 23, 2011 at 8:26 PM, Gustav Simonsson < gustav.simonsson@REDACTED> wrote: > > etop:start(). > > gives information similar to 'top' in UNIX: > http://www.erlang.org/doc/man/etop.html > > Regards, > Gustav Simonsson > > ----- Original Message ----- > From: "Muhammad Yousaf" > To: erlang-questions@REDACTED > Sent: Monday, May 23, 2011 1:00:32 PM GMT +01:00 Amsterdam / Berlin / Bern > / Rome / Stockholm / Vienna > Subject: [erlang-questions] Tool for performace evaluation > > > Hi, > > Is there any tools to evaluate the performance of a module in Erlang that > can show graphical interface for time elapse, memory usage, performance > benchmarks etc ?? > > or is there any alternative to do this in Erlang > > Thanks in advance > > Regards, > > > Muhammad Yousaf > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- --------------------------------------------------------------- ???????????????????? ???????????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mazen.harake@REDACTED Tue May 31 08:37:10 2011 From: mazen.harake@REDACTED (Mazen Harake) Date: Tue, 31 May 2011 08:37:10 +0200 Subject: [erlang-questions] Tool for performace evaluation In-Reply-To: References: <315503444.211231306153617444.JavaMail.root@zimbra> Message-ID: Try entop instead. https://github.com/mazenharake/entop /M On 31 May 2011 08:32, Andy W. Song wrote: > I run Erlang on a remote machine through SSH. When I fire up etop it get: > 1> etop:start(). > Application initialization failed: no display name and no $DISPLAY > environment variable > Error in startup script: no display name and no $DISPLAY environment > variable > while executing > "load /usr/lib/libtk8.4.so.0 Tk" > ("package ifneeded" script) > invoked from within > "package require Tk 8.3" > (file "/usr/lib/erlang/lib/gs-1.5.12/priv/gstk.tcl" line 7) > How can I use text mode? > Thanks > Andy > On Mon, May 23, 2011 at 8:26 PM, Gustav Simonsson > wrote: >> >> etop:start(). >> >> gives information similar to 'top' in UNIX: >> http://www.erlang.org/doc/man/etop.html >> >> Regards, >> Gustav Simonsson >> >> ----- Original Message ----- >> From: "Muhammad Yousaf" >> To: erlang-questions@REDACTED >> Sent: Monday, May 23, 2011 1:00:32 PM GMT +01:00 Amsterdam / Berlin / Bern >> / Rome / Stockholm / Vienna >> Subject: [erlang-questions] Tool for performace evaluation >> >> >> Hi, >> >> Is there any tools to evaluate the performance of a module in Erlang that >> can show graphical interface for time elapse, memory usage, performance >> benchmarks etc ?? >> >> or is there any alternative to do this in Erlang >> >> Thanks in advance >> >> Regards, >> >> >> Muhammad Yousaf >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > > > -- > --------------------------------------------------------------- > ???????????????????? > ???????????????????? > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > From wsongcn@REDACTED Tue May 31 09:20:18 2011 From: wsongcn@REDACTED (Andy W. Song) Date: Tue, 31 May 2011 15:20:18 +0800 Subject: [erlang-questions] Tool for performace evaluation In-Reply-To: References: <315503444.211231306153617444.JavaMail.root@zimbra> Message-ID: That works, thanks. Can you explain a little bit what those columns means such as hsize? Regards Andy 2011/5/31 Mazen Harake > Try entop instead. > > https://github.com/mazenharake/entop > > /M > > On 31 May 2011 08:32, Andy W. Song wrote: > > I run Erlang on a remote machine through SSH. When I fire up etop it get: > > 1> etop:start(). > > Application initialization failed: no display name and no $DISPLAY > > environment variable > > Error in startup script: no display name and no $DISPLAY environment > > variable > > while executing > > "load /usr/lib/libtk8.4.so.0 Tk" > > ("package ifneeded" script) > > invoked from within > > "package require Tk 8.3" > > (file "/usr/lib/erlang/lib/gs-1.5.12/priv/gstk.tcl" line 7) > > How can I use text mode? > > Thanks > > Andy > > On Mon, May 23, 2011 at 8:26 PM, Gustav Simonsson > > wrote: > >> > >> etop:start(). > >> > >> gives information similar to 'top' in UNIX: > >> http://www.erlang.org/doc/man/etop.html > >> > >> Regards, > >> Gustav Simonsson > >> > >> ----- Original Message ----- > >> From: "Muhammad Yousaf" > >> To: erlang-questions@REDACTED > >> Sent: Monday, May 23, 2011 1:00:32 PM GMT +01:00 Amsterdam / Berlin / > Bern > >> / Rome / Stockholm / Vienna > >> Subject: [erlang-questions] Tool for performace evaluation > >> > >> > >> Hi, > >> > >> Is there any tools to evaluate the performance of a module in Erlang > that > >> can show graphical interface for time elapse, memory usage, performance > >> benchmarks etc ?? > >> > >> or is there any alternative to do this in Erlang > >> > >> Thanks in advance > >> > >> Regards, > >> > >> > >> Muhammad Yousaf > >> > >> > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questions@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-questions > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questions@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > > -- > > --------------------------------------------------------------- > > ???????????????????? > > ???????????????????? > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > -- --------------------------------------------------------------- ???????????????????? ???????????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mazen.harake@REDACTED Tue May 31 09:31:23 2011 From: mazen.harake@REDACTED (Mazen Harake) Date: Tue, 31 May 2011 09:31:23 +0200 Subject: [erlang-questions] Tool for performace evaluation In-Reply-To: References: <315503444.211231306153617444.JavaMail.root@zimbra> Message-ID: Message Queue, Heap size, Stack size and Heap Total On 31 May 2011 09:20, Andy W. Song wrote: > That works, thanks. Can you explain a little bit what those columns means > such as hsize? > Regards > Andy > 2011/5/31 Mazen Harake >> >> Try entop instead. >> >> https://github.com/mazenharake/entop >> >> /M >> >> On 31 May 2011 08:32, Andy W. Song wrote: >> > I run Erlang on a remote machine through SSH. When I fire up etop it >> > get: >> > 1> etop:start(). >> > Application initialization failed: no display name and no $DISPLAY >> > environment variable >> > Error in startup script: no display name and no $DISPLAY environment >> > variable >> > while executing >> > "load /usr/lib/libtk8.4.so.0 Tk" >> > ("package ifneeded" script) >> > invoked from within >> > "package require Tk 8.3" >> > (file "/usr/lib/erlang/lib/gs-1.5.12/priv/gstk.tcl" line 7) >> > How can I use text mode? >> > Thanks >> > Andy >> > On Mon, May 23, 2011 at 8:26 PM, Gustav Simonsson >> > wrote: >> >> >> >> etop:start(). >> >> >> >> gives information similar to 'top' in UNIX: >> >> http://www.erlang.org/doc/man/etop.html >> >> >> >> Regards, >> >> Gustav Simonsson >> >> >> >> ----- Original Message ----- >> >> From: "Muhammad Yousaf" >> >> To: erlang-questions@REDACTED >> >> Sent: Monday, May 23, 2011 1:00:32 PM GMT +01:00 Amsterdam / Berlin / >> >> Bern >> >> / Rome / Stockholm / Vienna >> >> Subject: [erlang-questions] Tool for performace evaluation >> >> >> >> >> >> Hi, >> >> >> >> Is there any tools to evaluate the performance of a module in Erlang >> >> that >> >> can show graphical interface for time elapse, memory usage, performance >> >> benchmarks etc ?? >> >> >> >> or is there any alternative to do this in Erlang >> >> >> >> Thanks in advance >> >> >> >> Regards, >> >> >> >> >> >> Muhammad Yousaf >> >> >> >> >> >> _______________________________________________ >> >> erlang-questions mailing list >> >> erlang-questions@REDACTED >> >> http://erlang.org/mailman/listinfo/erlang-questions >> >> _______________________________________________ >> >> erlang-questions mailing list >> >> erlang-questions@REDACTED >> >> http://erlang.org/mailman/listinfo/erlang-questions >> > >> > >> > >> > -- >> > --------------------------------------------------------------- >> > ???????????????????? >> > ???????????????????? >> > >> > _______________________________________________ >> > erlang-questions mailing list >> > erlang-questions@REDACTED >> > http://erlang.org/mailman/listinfo/erlang-questions >> > >> > > > > > -- > --------------------------------------------------------------- > ???????????????????? > ???????????????????? > From wsongcn@REDACTED Tue May 31 09:42:32 2011 From: wsongcn@REDACTED (Andy W. Song) Date: Tue, 31 May 2011 15:42:32 +0800 Subject: [erlang-questions] Tool for performace evaluation In-Reply-To: References: <315503444.211231306153617444.JavaMail.root@zimbra> Message-ID: Is it possible to track processes' CPU usage? Thanks Andy 2011/5/31 Mazen Harake > Message Queue, Heap size, Stack size and Heap Total > > On 31 May 2011 09:20, Andy W. Song wrote: > > That works, thanks. Can you explain a little bit what those columns means > > such as hsize? > > Regards > > Andy > > 2011/5/31 Mazen Harake > >> > >> Try entop instead. > >> > >> https://github.com/mazenharake/entop > >> > >> /M > >> > >> On 31 May 2011 08:32, Andy W. Song wrote: > >> > I run Erlang on a remote machine through SSH. When I fire up etop it > >> > get: > >> > 1> etop:start(). > >> > Application initialization failed: no display name and no $DISPLAY > >> > environment variable > >> > Error in startup script: no display name and no $DISPLAY environment > >> > variable > >> > while executing > >> > "load /usr/lib/libtk8.4.so.0 Tk" > >> > ("package ifneeded" script) > >> > invoked from within > >> > "package require Tk 8.3" > >> > (file "/usr/lib/erlang/lib/gs-1.5.12/priv/gstk.tcl" line 7) > >> > How can I use text mode? > >> > Thanks > >> > Andy > >> > On Mon, May 23, 2011 at 8:26 PM, Gustav Simonsson > >> > wrote: > >> >> > >> >> etop:start(). > >> >> > >> >> gives information similar to 'top' in UNIX: > >> >> http://www.erlang.org/doc/man/etop.html > >> >> > >> >> Regards, > >> >> Gustav Simonsson > >> >> > >> >> ----- Original Message ----- > >> >> From: "Muhammad Yousaf" > >> >> To: erlang-questions@REDACTED > >> >> Sent: Monday, May 23, 2011 1:00:32 PM GMT +01:00 Amsterdam / Berlin / > >> >> Bern > >> >> / Rome / Stockholm / Vienna > >> >> Subject: [erlang-questions] Tool for performace evaluation > >> >> > >> >> > >> >> Hi, > >> >> > >> >> Is there any tools to evaluate the performance of a module in Erlang > >> >> that > >> >> can show graphical interface for time elapse, memory usage, > performance > >> >> benchmarks etc ?? > >> >> > >> >> or is there any alternative to do this in Erlang > >> >> > >> >> Thanks in advance > >> >> > >> >> Regards, > >> >> > >> >> > >> >> Muhammad Yousaf > >> >> > >> >> > >> >> _______________________________________________ > >> >> erlang-questions mailing list > >> >> erlang-questions@REDACTED > >> >> http://erlang.org/mailman/listinfo/erlang-questions > >> >> _______________________________________________ > >> >> erlang-questions mailing list > >> >> erlang-questions@REDACTED > >> >> http://erlang.org/mailman/listinfo/erlang-questions > >> > > >> > > >> > > >> > -- > >> > --------------------------------------------------------------- > >> > ???????????????????? > >> > ???????????????????? > >> > > >> > _______________________________________________ > >> > erlang-questions mailing list > >> > erlang-questions@REDACTED > >> > http://erlang.org/mailman/listinfo/erlang-questions > >> > > >> > > > > > > > > > -- > > --------------------------------------------------------------- > > ???????????????????? > > ???????????????????? > > > -- --------------------------------------------------------------- ???????????????????? ???????????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: From wsongcn@REDACTED Tue May 31 10:08:59 2011 From: wsongcn@REDACTED (Andy W. Song) Date: Tue, 31 May 2011 16:08:59 +0800 Subject: [erlang-questions] Cowboy vs Misultin In-Reply-To: References: Message-ID: I guess Misultin's handle_data function has some problem if TCP packets are large, perhaps larger than ethernet MTU. If I use 1536+2 WebSocket packet size, I got follow error form Misultin(I fill up char 'M' with my packet): http process <0.515.0> has died with reason: {function_clause, [{misultin_websocket, handle_data, ["MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM", [],#Port<0.1012>,<0.516.0>, http,true,<0.40.0>]}, {misultin_websocket,connect,4}, {misultin_http,handle_data,9}]}, removing from references of open connections On Tue, May 31, 2011 at 2:18 PM, Andy W. Song wrote: > I installed R14B03. > > I'm disappointed with my Erlang WebSocket client's performance. So I wrote > a C version using libev, code attached. > Usage: > ./new A B C > A/B/C have the same meaning of Erlang client. > > Here is the result with my new client: > > misultin_websocket_binary_example(file attached, no change to rest of > Misultin) > start 519M > 3.5G > CPU, with 550 Kbyte/s traffic about 23%. > > misultin_websocket_example > start 519M > 3.5G > CPU, with 550 Kbyte/s traffic about 25%. > > Packet size is 512 bytes, client sends packets, server echo. > > Cowboy can't pass my test this time. Connections start dropping from 20K, > don't know why. > > Regards > Andy > > On Mon, May 30, 2011 at 10:20 PM, Roberto Ostinelli wrote: > >> 2011/5/30 Andy W. Song >> >>> Version 14.a-dfsg-3 is what comes with Debian stable. It's on my company >>> machine which now doesn't have internet access anymore. >>> >>> Debian splits Erlang to a bunch of small packages. I may download a >>> single Erlang/OTP package and install manually later on. >>> >>> Thanks >>> Andy >>> >> >> misultin has just been updated in the master branch [0.8-dev] to support >> binary mode. >> >> i would be very interested if you could redo your tests using the binary >> example for websockets: >> >> https://github.com/ostinelli/misultin/blob/master/examples/misultin_websocket_binary_example.erl >> >> let's see if loic hit the spot :) >> >> r. >> > > > > -- > --------------------------------------------------------------- > ???????????????????? > ???????????????????? > > -- --------------------------------------------------------------- ???????????????????? ???????????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: From wsongcn@REDACTED Tue May 31 10:26:59 2011 From: wsongcn@REDACTED (Andy W. Song) Date: Tue, 31 May 2011 16:26:59 +0800 Subject: [erlang-questions] Cowboy vs Misultin In-Reply-To: References: Message-ID: 1400+2 WebSocket packet size is OK. Packet rate stays the same. CPU usage goes up from 24% to 37%. CPU usage proportion to packet size is not a good sign. handle_data() function will traverse the list to find 255, which is low efficient. Can it be improved? Regards Andy On Tue, May 31, 2011 at 4:08 PM, Andy W. Song wrote: > I guess Misultin's handle_data function has some problem if TCP packets are > large, perhaps larger than ethernet MTU. > > If I use 1536+2 WebSocket packet size, I got follow error form Misultin(I > fill up char 'M' with my packet): > > http process <0.515.0> has died with reason: {function_clause, > [{misultin_websocket, > handle_data, > > ["MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM", > > [],#Port<0.1012>,<0.516.0>, > http,true,<0.40.0>]}, > > {misultin_websocket,connect,4}, > > {misultin_http,handle_data,9}]}, removing from references of open > connections > > On Tue, May 31, 2011 at 2:18 PM, Andy W. Song wrote: > >> I installed R14B03. >> >> I'm disappointed with my Erlang WebSocket client's performance. So I >> wrote a C version using libev, code attached. >> Usage: >> ./new A B C >> A/B/C have the same meaning of Erlang client. >> >> Here is the result with my new client: >> >> misultin_websocket_binary_example(file attached, no change to rest of >> Misultin) >> start 519M >> 3.5G >> CPU, with 550 Kbyte/s traffic about 23%. >> >> misultin_websocket_example >> start 519M >> 3.5G >> CPU, with 550 Kbyte/s traffic about 25%. >> >> Packet size is 512 bytes, client sends packets, server echo. >> >> Cowboy can't pass my test this time. Connections start dropping from 20K, >> don't know why. >> >> Regards >> Andy >> >> On Mon, May 30, 2011 at 10:20 PM, Roberto Ostinelli wrote: >> >>> 2011/5/30 Andy W. Song >>> >>>> Version 14.a-dfsg-3 is what comes with Debian stable. It's on my company >>>> machine which now doesn't have internet access anymore. >>>> >>>> Debian splits Erlang to a bunch of small packages. I may download a >>>> single Erlang/OTP package and install manually later on. >>>> >>>> Thanks >>>> Andy >>>> >>> >>> misultin has just been updated in the master branch [0.8-dev] to support >>> binary mode. >>> >>> i would be very interested if you could redo your tests using the binary >>> example for websockets: >>> >>> https://github.com/ostinelli/misultin/blob/master/examples/misultin_websocket_binary_example.erl >>> >>> let's see if loic hit the spot :) >>> >>> r. >>> >> >> >> >> -- >> --------------------------------------------------------------- >> ???????????????????? >> ???????????????????? >> >> > > > -- > --------------------------------------------------------------- > ???????????????????? > ???????????????????? > > -- --------------------------------------------------------------- ???????????????????? ???????????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: From gleber.p@REDACTED Tue May 31 10:43:59 2011 From: gleber.p@REDACTED (Gleb Peregud) Date: Tue, 31 May 2011 10:43:59 +0200 Subject: [erlang-questions] Tool for performace evaluation In-Reply-To: References: <315503444.211231306153617444.JavaMail.root@zimbra> Message-ID: On Tue, May 31, 2011 at 09:42, Andy W. Song wrote: > Is it possible to track processes' CPU usage? Try https://github.com/massemanet/eper From attila.r.nohl@REDACTED Tue May 31 10:48:48 2011 From: attila.r.nohl@REDACTED (Attila Rajmund Nohl) Date: Tue, 31 May 2011 10:48:48 +0200 Subject: [erlang-questions] halfword emulator state In-Reply-To: References: Message-ID: 2011/5/30, Paolo Negri : > Dear list > > I would like to assess the state of development and recommended usage > of the halfword emulator. > > Apart from the initial announcement [1] and the fixes/improvements > introduced with R14B03 [2] there hasn't been much discussion about it. > As we're evaluating the use of the halfword emulator in production I > would like to ask questions. > > - Is anyone already using the halfword emulator in production > environments, if yes, are what are the experiences, is it stable, what > are the effective gains, is there any measurable overhead? We've had some emulator crashes on R14B02 (since fixed in R14B03), so I definitely not advise the halfword emulator in R14B02. Apart from this bug it was quite stable. Unfortunately it turned out that some of our Erlang processes use a lot more memory than we expected, so due to the 4GB limit for process memory we couldn't decrease the number of running Erlang VMs, that's why we stayed with the 32 bit emulator currently. We'll have an other go with R14B03. From mazen.harake@REDACTED Tue May 31 10:53:30 2011 From: mazen.harake@REDACTED (Mazen Harake) Date: Tue, 31 May 2011 10:53:30 +0200 Subject: [erlang-questions] Tool for performace evaluation In-Reply-To: References: <315503444.211231306153617444.JavaMail.root@zimbra> Message-ID: Not per process since they aren't actual OS processes. You should look at "Reductions" because that tells you how "active" a process is. You can also look at "RpI" which means "Reductions per Interval" which means how active the node has been since the tool last polled it. In terms of actual process usage of the virtual machine you can simply use top but it is very hard to determine how much CPU an individual process uses. /M On 31 May 2011 09:42, Andy W. Song wrote: > Is it possible to track processes' CPU usage? > Thanks > Andy > > 2011/5/31 Mazen Harake >> >> Message Queue, Heap size, Stack size and Heap Total >> >> On 31 May 2011 09:20, Andy W. Song wrote: >> > That works, thanks. Can you explain a little bit what those columns >> > means >> > such as hsize? >> > Regards >> > Andy >> > 2011/5/31 Mazen Harake >> >> >> >> Try entop instead. >> >> >> >> https://github.com/mazenharake/entop >> >> >> >> /M >> >> >> >> On 31 May 2011 08:32, Andy W. Song wrote: >> >> > I run Erlang on a remote machine through SSH. When I fire up etop it >> >> > get: >> >> > 1> etop:start(). >> >> > Application initialization failed: no display name and no $DISPLAY >> >> > environment variable >> >> > Error in startup script: no display name and no $DISPLAY environment >> >> > variable >> >> > while executing >> >> > "load /usr/lib/libtk8.4.so.0 Tk" >> >> > ("package ifneeded" script) >> >> > invoked from within >> >> > "package require Tk 8.3" >> >> > (file "/usr/lib/erlang/lib/gs-1.5.12/priv/gstk.tcl" line 7) >> >> > How can I use text mode? >> >> > Thanks >> >> > Andy >> >> > On Mon, May 23, 2011 at 8:26 PM, Gustav Simonsson >> >> > wrote: >> >> >> >> >> >> etop:start(). >> >> >> >> >> >> gives information similar to 'top' in UNIX: >> >> >> http://www.erlang.org/doc/man/etop.html >> >> >> >> >> >> Regards, >> >> >> Gustav Simonsson >> >> >> >> >> >> ----- Original Message ----- >> >> >> From: "Muhammad Yousaf" >> >> >> To: erlang-questions@REDACTED >> >> >> Sent: Monday, May 23, 2011 1:00:32 PM GMT +01:00 Amsterdam / Berlin >> >> >> / >> >> >> Bern >> >> >> / Rome / Stockholm / Vienna >> >> >> Subject: [erlang-questions] Tool for performace evaluation >> >> >> >> >> >> >> >> >> Hi, >> >> >> >> >> >> Is there any tools to evaluate the performance of a module in Erlang >> >> >> that >> >> >> can show graphical interface for time elapse, memory usage, >> >> >> performance >> >> >> benchmarks etc ?? >> >> >> >> >> >> or is there any alternative to do this in Erlang >> >> >> >> >> >> Thanks in advance >> >> >> >> >> >> Regards, >> >> >> >> >> >> >> >> >> Muhammad Yousaf >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> erlang-questions mailing list >> >> >> erlang-questions@REDACTED >> >> >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> _______________________________________________ >> >> >> erlang-questions mailing list >> >> >> erlang-questions@REDACTED >> >> >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > >> >> > >> >> > >> >> > -- >> >> > --------------------------------------------------------------- >> >> > ???????????????????? >> >> > ???????????????????? >> >> > >> >> > _______________________________________________ >> >> > erlang-questions mailing list >> >> > erlang-questions@REDACTED >> >> > http://erlang.org/mailman/listinfo/erlang-questions >> >> > >> >> > >> > >> > >> > >> > -- >> > --------------------------------------------------------------- >> > ???????????????????? >> > ???????????????????? >> > > > > > -- > --------------------------------------------------------------- > ???????????????????? > ???????????????????? > From tobias.rodaebel@REDACTED Tue May 31 11:01:30 2011 From: tobias.rodaebel@REDACTED (Tobias) Date: Tue, 31 May 2011 11:01:30 +0200 Subject: [erlang-questions] Cowboy vs Misultin In-Reply-To: References: Message-ID: <2EDF7C33-38EE-4E70-8C73-996FCFD6C62A@googlemail.com> Hi Andy, I'm kind of fresh to Erlang and wrote a standalone Web Socket server as a learning project. Just out of curiosity, would you mind to run your tests against my implementation just to get an idea if I'm on the right track? https://github.com/rodaebel/ewsd $ cd ewsd; $ make $ bin/ewsd The default handler just echoes incoming Web Socket messages. Thanks in advance, Tobias On May 31, 2011, at 10:26 AM, Andy W. Song wrote: > 1400+2 WebSocket packet size is OK. Packet rate stays the same. CPU usage goes up from 24% to 37%. > > CPU usage proportion to packet size is not a good sign. handle_data() function will traverse the list to find 255, which is low efficient. Can it be improved? > > Regards > Andy > > On Tue, May 31, 2011 at 4:08 PM, Andy W. Song wrote: > I guess Misultin's handle_data function has some problem if TCP packets are large, perhaps larger than ethernet MTU. > > If I use 1536+2 WebSocket packet size, I got follow error form Misultin(I fill up char 'M' with my packet): > > http process <0.515.0> has died with reason: {function_clause, > [{misultin_websocket, > handle_data, > ["MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM", > [],#Port<0.1012>,<0.516.0>, > http,true,<0.40.0>]}, > {misultin_websocket,connect,4}, > {misultin_http,handle_data,9}]}, removing from references of open connections > > On Tue, May 31, 2011 at 2:18 PM, Andy W. Song wrote: > I installed R14B03. > > I'm disappointed with my Erlang WebSocket client's performance. So I wrote a C version using libev, code attached. > Usage: > ./new A B C > A/B/C have the same meaning of Erlang client. > > Here is the result with my new client: > > misultin_websocket_binary_example(file attached, no change to rest of Misultin) > start 519M > 3.5G > CPU, with 550 Kbyte/s traffic about 23%. > > misultin_websocket_example > start 519M > 3.5G > CPU, with 550 Kbyte/s traffic about 25%. > > Packet size is 512 bytes, client sends packets, server echo. > > Cowboy can't pass my test this time. Connections start dropping from 20K, don't know why. > > Regards > Andy > > On Mon, May 30, 2011 at 10:20 PM, Roberto Ostinelli wrote: > 2011/5/30 Andy W. Song > Version 14.a-dfsg-3 is what comes with Debian stable. It's on my company machine which now doesn't have internet access anymore. > > Debian splits Erlang to a bunch of small packages. I may download a single Erlang/OTP package and install manually later on. > > Thanks > Andy > > misultin has just been updated in the master branch [0.8-dev] to support binary mode. > > i would be very interested if you could redo your tests using the binary example for websockets: > https://github.com/ostinelli/misultin/blob/master/examples/misultin_websocket_binary_example.erl > > let's see if loic hit the spot :) > > r. > > > > -- > --------------------------------------------------------------- > ???????????????????? > ???????????????????? > > > > > -- > --------------------------------------------------------------- > ???????????????????? > ???????????????????? > > > > > -- > --------------------------------------------------------------- > ???????????????????? > ???????????????????? > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From watson.timothy@REDACTED Tue May 31 11:02:00 2011 From: watson.timothy@REDACTED (Tim Watson) Date: Tue, 31 May 2011 10:02:00 +0100 Subject: [erlang-questions] Best way to integrate QuickCheck and rebar In-Reply-To: References: Message-ID: On 30 May 2011 19:48, Francis Joanis wrote: > Hi, > > I am new to both rebar and QuickCheck and I'm looking for a way to have > rebar invoke my QuickCheck tests. The only thing I've found so far is to > have an eunit test invoke QuickCheck from within its test. > > What would be the best way to achieve this? Embedding your PropEr/QuickCheck tests in eunit and/or common_test suites is the best thing to do right now, because both these options afford you test+main code compilation support, code coverage and test report generation. There is no direct way to run PropEr/QuickCheck properties with rebar, and whilst it's possible to write a plugin to do this, there's quite a lot of work involved (take the rebar_eunit module as an example of what needs to be done). From roberto@REDACTED Tue May 31 11:13:15 2011 From: roberto@REDACTED (Roberto Ostinelli) Date: Tue, 31 May 2011 11:13:15 +0200 Subject: [erlang-questions] Erlang and Memory management Message-ID: Dear list, I'd like to know some inner insights on how memory is handled in Erlang. Let's say that I build up a Binary term() in a gen_server, which I store in its state, and then send it over to another gen_server which will also store this term into its state. My question is: will this Binary term occupy 2 * memory space or is there some kind of pointer mechanism to handle it? Thank you, r. -------------- next part -------------- An HTML attachment was scrubbed... URL: From xramtsov@REDACTED Tue May 31 11:20:33 2011 From: xramtsov@REDACTED (Evgeniy Khramtsov) Date: Tue, 31 May 2011 19:20:33 +1000 Subject: [erlang-questions] Erlang and Memory management In-Reply-To: References: Message-ID: <4DE4B2E1.2050708@gmail.com> 31.05.2011 19:13, Roberto Ostinelli wrote: > My question is: will this Binary term occupy 2 * memory space or is there > some kind of pointer mechanism to handle it? > As I understand from binary.c, small binaries are kept on a process heap (ERL_ONHEAP_BIN_LIMIT = 64), so they will likely be copied. Bigger binaries are allocated on shared heap, so only a pointer will be copied. -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:xram@REDACTED From olopierpa@REDACTED Tue May 31 11:20:52 2011 From: olopierpa@REDACTED (Pierpaolo Bernardi) Date: Tue, 31 May 2011 11:20:52 +0200 Subject: [erlang-questions] Erlang and Memory management In-Reply-To: References: Message-ID: On Tue, May 31, 2011 at 11:13, Roberto Ostinelli wrote: > Dear list, > > I'd like to know some inner insights on how memory is handled in Erlang. > > Let's say that I build up a Binary term() in a gen_server, which I store in > its state, and then send it over to another gen_server which will also store > this term into its state. > > My question is: will this Binary term occupy 2 * memory space or is there > some kind of pointer mechanism to handle it? This is explained here: http://www.erlang.org/doc/efficiency_guide/binaryhandling.html#id58893 P. From essen@REDACTED Tue May 31 11:30:24 2011 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 31 May 2011 11:30:24 +0200 Subject: [erlang-questions] Cowboy vs Misultin In-Reply-To: References: Message-ID: <4DE4B530.30307@dev-extend.eu> Hello, Did you try my proposed changes? On 05/31/2011 08:18 AM, Andy W. Song wrote: > Cowboy can't pass my test this time. Connections start dropping from > 20K, don't know why. Works fine here. I've noted a few more things however: * Your hibernate call is in the wrong place, it should be right before the receive, as there could be more than one frame queued and you'll ignore it by hibernating right after the reply to the first frame. * You should use erlang:hibernate, not proc_lib:hibernate, as this process isn't started using proc_lib. * If you don't need the HTTP headers or any HTTP stuff from the request after socket initialization, you should just remove it from the record. Include "cowboy/http.hrl" and change the #http_req contents to remove the extra cruft. You'll use less than half you currently use doing this. -- Lo?c Hoguin Dev:Extend From wsongcn@REDACTED Tue May 31 11:36:11 2011 From: wsongcn@REDACTED (Andy W. Song) Date: Tue, 31 May 2011 17:36:11 +0800 Subject: [erlang-questions] Cowboy vs Misultin In-Reply-To: <2EDF7C33-38EE-4E70-8C73-996FCFD6C62A@googlemail.com> References: <2EDF7C33-38EE-4E70-8C73-996FCFD6C62A@googlemail.com> Message-ID: Too many prints. Can't go fast enough. On Tue, May 31, 2011 at 5:01 PM, Tobias wrote: > Hi Andy, > > I'm kind of fresh to Erlang and wrote a standalone Web Socket server as a > learning project. Just out of curiosity, would you mind to run your tests > against my implementation just to get an idea if I'm on the right track? > > https://github.com/rodaebel/ewsd > > $ cd ewsd; > $ make > $ bin/ewsd > > The default handler just echoes incoming Web Socket messages. > > Thanks in advance, > Tobias > > On May 31, 2011, at 10:26 AM, Andy W. Song wrote: > > 1400+2 WebSocket packet size is OK. Packet rate stays the same. CPU usage > goes up from 24% to 37%. > > CPU usage proportion to packet size is not a good sign. handle_data() > function will traverse the list to find 255, which is low efficient. Can it > be improved? > > Regards > Andy > > On Tue, May 31, 2011 at 4:08 PM, Andy W. Song wrote: > >> I guess Misultin's handle_data function has some problem if TCP packets >> are large, perhaps larger than ethernet MTU. >> >> If I use 1536+2 WebSocket packet size, I got follow error form Misultin(I >> fill up char 'M' with my packet): >> >> http process <0.515.0> has died with reason: {function_clause, >> [{misultin_websocket, >> handle_data, >> >> ["MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM", >> >> [],#Port<0.1012>,<0.516.0>, >> http,true,<0.40.0>]}, >> >> {misultin_websocket,connect,4}, >> >> {misultin_http,handle_data,9}]}, removing from references of open >> connections >> >> On Tue, May 31, 2011 at 2:18 PM, Andy W. Song wrote: >> >>> I installed R14B03. >>> >>> I'm disappointed with my Erlang WebSocket client's performance. So I >>> wrote a C version using libev, code attached. >>> Usage: >>> ./new A B C >>> A/B/C have the same meaning of Erlang client. >>> >>> Here is the result with my new client: >>> >>> misultin_websocket_binary_example(file attached, no change to rest of >>> Misultin) >>> start 519M >>> 3.5G >>> CPU, with 550 Kbyte/s traffic about 23%. >>> >>> misultin_websocket_example >>> start 519M >>> 3.5G >>> CPU, with 550 Kbyte/s traffic about 25%. >>> >>> Packet size is 512 bytes, client sends packets, server echo. >>> >>> Cowboy can't pass my test this time. Connections start dropping from 20K, >>> don't know why. >>> >>> Regards >>> Andy >>> >>> On Mon, May 30, 2011 at 10:20 PM, Roberto Ostinelli >> > wrote: >>> >>>> 2011/5/30 Andy W. Song >>>> >>>>> Version 14.a-dfsg-3 is what comes with Debian stable. It's on my >>>>> company machine which now doesn't have internet access anymore. >>>>> >>>>> Debian splits Erlang to a bunch of small packages. I may download a >>>>> single Erlang/OTP package and install manually later on. >>>>> >>>>> Thanks >>>>> Andy >>>>> >>>> >>>> misultin has just been updated in the master branch [0.8-dev] to support >>>> binary mode. >>>> >>>> i would be very interested if you could redo your tests using the binary >>>> example for websockets: >>>> >>>> https://github.com/ostinelli/misultin/blob/master/examples/misultin_websocket_binary_example.erl >>>> >>>> let's see if loic hit the spot :) >>>> >>>> r. >>>> >>> >>> >>> >>> -- >>> --------------------------------------------------------------- >>> ???????????????????? >>> ???????????????????? >>> >>> >> >> >> -- >> --------------------------------------------------------------- >> ???????????????????? >> ???????????????????? >> >> > > > -- > --------------------------------------------------------------- > ???????????????????? > ???????????????????? > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > -- --------------------------------------------------------------- ???????????????????? ???????????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: From yuchao1@REDACTED Tue May 31 11:41:11 2011 From: yuchao1@REDACTED (=?GB2312?B?0+CzrA==?=) Date: Tue, 31 May 2011 17:41:11 +0800 Subject: [erlang-questions] erlang md5 function and other encryption function Message-ID: <4DE4B7B7.7020806@staff.sina.com.cn> Joe: hi have your litter time for ask some encryption function, for example : Now, I 'm used java encrypted the exchange data form my company to China Bank. using MessageDiggest java class ,package java.security.*;and javax.crypto.*; I want to know : Had the same encryption and decryption function use erlang? we needs safe data exchange in my bank erlang system. thanks -- Best Regards ??(Yu Chao) ???????-?????? ????8610?62676661 13466539920 ????8610?82607158 Email: yuchao1@REDACTED MSN: yuchao86@REDACTED UC:yuchao86@REDACTED ??????????????58???????15?25-2? _________________________________________________________ http://www.sina.com.cn You're the One ??.?? ?????? From wsongcn@REDACTED Tue May 31 11:48:22 2011 From: wsongcn@REDACTED (Andy W. Song) Date: Tue, 31 May 2011 17:48:22 +0800 Subject: [erlang-questions] Cowboy vs Misultin In-Reply-To: <4DE4B530.30307@dev-extend.eu> References: <4DE4B530.30307@dev-extend.eu> Message-ID: Do you mean these two? * L139: binary:match is probably too expensive to simply find byte 255. * L176: we are constructing a new binary that copies the message to send I tried to convert the second one to iolist, with no effect. The first one I didn't change. All my change to Cowboy is attached in a diff file in my previous post. Can you cook a new diff that I can apply to your stock version with your proposed change so that I can try? Thanks Andy On Tue, May 31, 2011 at 5:30 PM, Lo?c Hoguin wrote: > Hello, > > Did you try my proposed changes? > > On 05/31/2011 08:18 AM, Andy W. Song wrote: > > Cowboy can't pass my test this time. Connections start dropping from > > 20K, don't know why. > > Works fine here. > Do you mean using my C version client? > > I've noted a few more things however: > > * Your hibernate call is in the wrong place, it should be right before > the receive, as there could be more than one frame queued and you'll > ignore it by hibernating right after the reply to the first frame. > I don't think so. If before receive, what parameter do you give hibernate? And in my test, each connection will receive only one packet in every 5 minutes. So there is no queued up frame at all and that is the reason to use hibernate. > * You should use erlang:hibernate, not proc_lib:hibernate, as this > process isn't started using proc_lib. > Tried, no difference. > > * If you don't need the HTTP headers or any HTTP stuff from the request > after socket initialization, you should just remove it from the record. > Include "cowboy/http.hrl" and change the #http_req contents to remove > the extra cruft. You'll use less than half you currently use doing this. > > -- > Lo?c Hoguin > Dev:Extend > -- --------------------------------------------------------------- ???????????????????? ???????????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: From norton@REDACTED Tue May 31 11:53:13 2011 From: norton@REDACTED (Joseph Wayne Norton) Date: Tue, 31 May 2011 18:53:13 +0900 Subject: [erlang-questions] file module - missing raw operations? In-Reply-To: <4DE4B790.1020308@erlang.org> References: <4DE4B790.1020308@erlang.org> Message-ID: Hello. I have a question indirectly related to the patch below. During a recent performance benchmarking exercise, we learned that a subset of the file module's operations do not have an raw i/o API. https://github.com/hibari/basho_bench/commit/3387e7e9c278940ca54dfde010066ddb3d255be8 Is this omission accidental or deliberate? Could new APIs be added to the file module in the future? thanks, ------- Forwarded message ------- From: "Henrik Nord" To: "Stavros Aronis" Cc: "Erlang Patches" Subject: Re: [erlang-patches] Discrepancy in prim_file Date: Tue, 31 May 2011 18:40:32 +0900 On 05/28/2011 11:17 AM, Stavros Aronis wrote: > Details in the commit message: > > git fetch git://github.com/aronisstav/otp.git prim-file-fix > > I've tested this patch by running: > - the test suite kernel/prim_file_SUITE > - the experimental version of Dialyzer that discovered the discrepancy > (nearly all of the warnings in > http://dialyzer.softlab.ntua.gr/intersection/disco and all the > warnings in http://dialyzer.softlab.ntua.gr/intersection/otp-erts stem > from this discrepancy. Other applications affected include OTP kernel > and ssl, hibari, scalaris and yaws.) > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Thank you Stavros I have included this in 'pu', and will let it cook for a few days. -- norton@REDACTED From roberto@REDACTED Tue May 31 12:01:02 2011 From: roberto@REDACTED (Roberto Ostinelli) Date: Tue, 31 May 2011 12:01:02 +0200 Subject: [erlang-questions] Cowboy vs Misultin In-Reply-To: References: Message-ID: 2011/5/31 Andy W. Song > I guess Misultin's handle_data function has some problem if TCP packets are > large, perhaps larger than ethernet MTU. > > If I use 1536+2 WebSocket packet size, I got follow error form Misultin(I > fill up char 'M' with my packet): > I have tested a packet size of 150K without any issues. 2011/5/31 Andy W. Song > 1400+2 WebSocket packet size is OK. Packet rate stays the same. CPU usage > goes up from 24% to 37%. > > CPU usage proportion to packet size is not a good sign. handle_data() > function will traverse the list to find 255, which is low efficient. Can it > be improved? > I'm currently working on this. Latest misultin commit now handles the parsing of websocket data in binary instead of lists. r. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto@REDACTED Tue May 31 12:09:28 2011 From: roberto@REDACTED (Roberto Ostinelli) Date: Tue, 31 May 2011 12:09:28 +0200 Subject: [erlang-questions] Erlang and Memory management In-Reply-To: References: Message-ID: 2011/5/31 Pierpaolo Bernardi > > This is explained here: > http://www.erlang.org/doc/efficiency_guide/binaryhandling.html#id58893 > > I've probably tried to oversimplify my user case. What happens in case of lists? r. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gleber.p@REDACTED Tue May 31 12:19:40 2011 From: gleber.p@REDACTED (Gleb Peregud) Date: Tue, 31 May 2011 12:19:40 +0200 Subject: [erlang-questions] Erlang and Memory management In-Reply-To: References: Message-ID: On Tue, May 31, 2011 at 12:09, Roberto Ostinelli wrote: > What happens in case of lists? All other structures are copied, hence occupying memory twice. Although there are special rules for "constant pool" structures. From tobias.rodaebel@REDACTED Tue May 31 12:22:55 2011 From: tobias.rodaebel@REDACTED (Tobias) Date: Tue, 31 May 2011 12:22:55 +0200 Subject: [erlang-questions] Cowboy vs Misultin In-Reply-To: References: <2EDF7C33-38EE-4E70-8C73-996FCFD6C62A@googlemail.com> Message-ID: <13AC04FF-F74E-4EA1-B369-FBECEEC1512A@googlemail.com> Andy, Thanks for the hint! Lesson learned :) I have removed the error_logger:info_msg calls. Regards, Tobias On May 31, 2011, at 11:36 AM, Andy W. Song wrote: > Too many prints. Can't go fast enough. > > On Tue, May 31, 2011 at 5:01 PM, Tobias wrote: > Hi Andy, > > I'm kind of fresh to Erlang and wrote a standalone Web Socket server as a learning project. Just out of curiosity, would you mind to run your tests against my implementation just to get an idea if I'm on the right track? > > https://github.com/rodaebel/ewsd > > $ cd ewsd; > $ make > $ bin/ewsd > > The default handler just echoes incoming Web Socket messages. > > Thanks in advance, > Tobias > > On May 31, 2011, at 10:26 AM, Andy W. Song wrote: > >> 1400+2 WebSocket packet size is OK. Packet rate stays the same. CPU usage goes up from 24% to 37%. >> >> CPU usage proportion to packet size is not a good sign. handle_data() function will traverse the list to find 255, which is low efficient. Can it be improved? >> >> Regards >> Andy >> >> On Tue, May 31, 2011 at 4:08 PM, Andy W. Song wrote: >> I guess Misultin's handle_data function has some problem if TCP packets are large, perhaps larger than ethernet MTU. >> >> If I use 1536+2 WebSocket packet size, I got follow error form Misultin(I fill up char 'M' with my packet): >> >> http process <0.515.0> has died with reason: {function_clause, >> [{misultin_websocket, >> handle_data, >> ["MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM", >> [],#Port<0.1012>,<0.516.0>, >> http,true,<0.40.0>]}, >> {misultin_websocket,connect,4}, >> {misultin_http,handle_data,9}]}, removing from references of open connections >> >> On Tue, May 31, 2011 at 2:18 PM, Andy W. Song wrote: >> I installed R14B03. >> >> I'm disappointed with my Erlang WebSocket client's performance. So I wrote a C version using libev, code attached. >> Usage: >> ./new A B C >> A/B/C have the same meaning of Erlang client. >> >> Here is the result with my new client: >> >> misultin_websocket_binary_example(file attached, no change to rest of Misultin) >> start 519M >> 3.5G >> CPU, with 550 Kbyte/s traffic about 23%. >> >> misultin_websocket_example >> start 519M >> 3.5G >> CPU, with 550 Kbyte/s traffic about 25%. >> >> Packet size is 512 bytes, client sends packets, server echo. >> >> Cowboy can't pass my test this time. Connections start dropping from 20K, don't know why. >> >> Regards >> Andy >> >> On Mon, May 30, 2011 at 10:20 PM, Roberto Ostinelli wrote: >> 2011/5/30 Andy W. Song >> Version 14.a-dfsg-3 is what comes with Debian stable. It's on my company machine which now doesn't have internet access anymore. >> >> Debian splits Erlang to a bunch of small packages. I may download a single Erlang/OTP package and install manually later on. >> >> Thanks >> Andy >> >> misultin has just been updated in the master branch [0.8-dev] to support binary mode. >> >> i would be very interested if you could redo your tests using the binary example for websockets: >> https://github.com/ostinelli/misultin/blob/master/examples/misultin_websocket_binary_example.erl >> >> let's see if loic hit the spot :) >> >> r. >> >> >> >> -- >> --------------------------------------------------------------- >> ???????????????????? >> ???????????????????? >> >> >> >> >> -- >> --------------------------------------------------------------- >> ???????????????????? >> ???????????????????? >> >> >> >> >> -- >> --------------------------------------------------------------- >> ???????????????????? >> ???????????????????? >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > > > > -- > --------------------------------------------------------------- > ???????????????????? > ???????????????????? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From olopierpa@REDACTED Tue May 31 12:27:53 2011 From: olopierpa@REDACTED (Pierpaolo Bernardi) Date: Tue, 31 May 2011 12:27:53 +0200 Subject: [erlang-questions] Erlang and Memory management In-Reply-To: References: Message-ID: On Tue, May 31, 2011 at 12:09, Roberto Ostinelli wrote: > 2011/5/31 Pierpaolo Bernardi >> >> This is explained here: >> http://www.erlang.org/doc/efficiency_guide/binaryhandling.html#id58893 >> > > I've probably tried to oversimplify my user case. > > What happens in case of lists? What Gleb said. (You can check here: http://www.erlang.org/doc/efficiency_guide/processes.html#id67714 if you don't trust Gleb 8^) P. From wsongcn@REDACTED Tue May 31 12:54:48 2011 From: wsongcn@REDACTED (Andy W. Song) Date: Tue, 31 May 2011 18:54:48 +0800 Subject: [erlang-questions] Cowboy vs Misultin In-Reply-To: References: Message-ID: Would you mind testing it using my C client? Search "->len" and give it a value between 1500 and 2000, hopefully you'll see the result I saw. Regards Andy On 5/31/11, Roberto Ostinelli wrote: > 2011/5/31 Andy W. Song > >> I guess Misultin's handle_data function has some problem if TCP packets >> are >> large, perhaps larger than ethernet MTU. >> >> If I use 1536+2 WebSocket packet size, I got follow error form Misultin(I >> fill up char 'M' with my packet): >> > > I have tested a packet size of 150K without any issues. > > > 2011/5/31 Andy W. Song > >> 1400+2 WebSocket packet size is OK. Packet rate stays the same. CPU usage >> goes up from 24% to 37%. >> >> CPU usage proportion to packet size is not a good sign. handle_data() >> function will traverse the list to find 255, which is low efficient. Can >> it >> be improved? >> > > I'm currently working on this. Latest misultin commit now handles the > parsing of websocket data in binary instead of lists. > > r. > -- Sent from my mobile device --------------------------------------------------------------- ???????????????????? ???????????????????? From wallentin.dahlberg@REDACTED Tue May 31 13:27:23 2011 From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=) Date: Tue, 31 May 2011 13:27:23 +0200 Subject: [erlang-questions] halfword emulator state In-Reply-To: References: <75BA56C3-F3C9-435D-AA4A-6B1E2AA3B816@cs.otago.ac.nz> <20110531034654.GA24891@mulga.csse.unimelb.edu.au> Message-ID: <8988806716269872934@unknownmsgid> Perhaps the vanilla x86_64 beam should be called doubleword beam. And no halfword. It always struck me as strange that erlangs wordsize was dependent on what machine it was running on. // Bj?rn-Egil Skickat fr?n min iPhone 31 maj 2011 kl. 07:10 skrev OvermindDL1 : On May 30, 2011 9:47 PM, "Jeff Schultz" wrote: > > On Tue, May 31, 2011 at 03:38:57PM +1200, Richard O'Keefe wrote: > > On 31/05/2011, at 8:20 AM, Paolo Negri wrote: > > > I would like to assess the state of development and recommended usage > > > of the halfword emulator. > > > Could I just make the point that "halfword" is confusing? > > I thought it referred to 16-bit units of something. > > It might be clearer if called the "small pointer emulator" > > or something like that. > > Or "compact pointer emulator" or "compact address emulator." > > > Jeff Schultz Was it not only for 64bit, hence a halfword will only be 32bit, not 16bit? _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From hd2010@REDACTED Tue May 31 13:46:22 2011 From: hd2010@REDACTED (H. Diedrich) Date: Tue, 31 May 2011 13:46:22 +0200 Subject: [erlang-questions] [eeps] New EEP draft: -discontiguous declaration In-Reply-To: <90ADDBCD-A7B5-4A22-9761-CCD1236FA87D@cs.otago.ac.nz> References: <57545354d533b750b78e973473b64dd1.squirrel@chasm.otago.ac.nz> <20110527140051.GB1370@erix.ericsson.se> <253C4D1E-8AF6-4284-8DAB-6E8F6940BB40@cs.otago.ac.nz> <20110530094909.GA12629@erix.ericsson.se> <90ADDBCD-A7B5-4A22-9761-CCD1236FA87D@cs.otago.ac.nz> Message-ID: <4DE4D50E.5020701@eonblast.com> An HTML attachment was scrubbed... URL: From attila.r.nohl@REDACTED Tue May 31 14:53:56 2011 From: attila.r.nohl@REDACTED (Attila Rajmund Nohl) Date: Tue, 31 May 2011 14:53:56 +0200 Subject: [erlang-questions] halfword emulator state In-Reply-To: <8988806716269872934@unknownmsgid> References: <75BA56C3-F3C9-435D-AA4A-6B1E2AA3B816@cs.otago.ac.nz> <20110531034654.GA24891@mulga.csse.unimelb.edu.au> <8988806716269872934@unknownmsgid> Message-ID: Maybe because that's not Erlang word size, but machine word size :-) What I've found strange is that erlang:process_info returns the heap size in words but erlang:system_info shows the memory used by processes in bytes. 2011/5/31, Bj?rn-Egil Dahlberg : > Perhaps the vanilla x86_64 beam should be called doubleword beam. And no > halfword. > > It always struck me as strange that erlangs wordsize was dependent on what > machine it was running on. > > // Bj?rn-Egil > Skickat fr?n min iPhone > > 31 maj 2011 kl. 07:10 skrev OvermindDL1 : > > > On May 30, 2011 9:47 PM, "Jeff Schultz" wrote: >> >> On Tue, May 31, 2011 at 03:38:57PM +1200, Richard O'Keefe wrote: >> > On 31/05/2011, at 8:20 AM, Paolo Negri wrote: >> > > I would like to assess the state of development and recommended usage >> > > of the halfword emulator. >> >> > Could I just make the point that "halfword" is confusing? >> > I thought it referred to 16-bit units of something. >> > It might be clearer if called the "small pointer emulator" >> > or something like that. >> >> Or "compact pointer emulator" or "compact address emulator." >> >> >> Jeff Schultz > > Was it not only for 64bit, hence a halfword will only be 32bit, not 16bit? > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From raimo+erlang-questions@REDACTED Tue May 31 15:41:09 2011 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Tue, 31 May 2011 15:41:09 +0200 Subject: [erlang-questions] [eeps] New EEP draft: -discontiguous declaration In-Reply-To: <4DE4D50E.5020701@eonblast.com> References: <57545354d533b750b78e973473b64dd1.squirrel@chasm.otago.ac.nz> <20110527140051.GB1370@erix.ericsson.se> <253C4D1E-8AF6-4284-8DAB-6E8F6940BB40@cs.otago.ac.nz> <20110530094909.GA12629@erix.ericsson.se> <90ADDBCD-A7B5-4A22-9761-CCD1236FA87D@cs.otago.ac.nz> <4DE4D50E.5020701@eonblast.com> Message-ID: <20110531134109.GA15150@erix.ericsson.se> Please keep mails on this list in plaintext. On Tue, May 31, 2011 at 01:46:22PM +0200, H. Diedrich wrote: > > > > > > > > Richard O'Keefe schrieb: >
cite="mid:90ADDBCD-A7B5-4A22-9761-CCD1236FA87D@REDACTED" > type="cite"> >
On 30/05/2011, at 9:49 PM, Raimo Niskanen wrote:
> 
>   
>
>
On Mon, May 30, 2011 at 01:55:11PM +1200, Richard O'Keefe wrote:
>     
>
>
On 28/05/2011, at 2:00 AM, Raimo Niskanen wrote:
> 
>       
>
>
I'm sorry, we have changed EEP format into Markdown.
> See EEP 33:   href="http://www.erlang.org/eeps/eep-0033.html">http://www.erlang.org/eeps/eep-0033.html
> 
> I am not sure if this has been communicated properly,
>         
>
>
I wasn't aware of this at all, and am rather upset about
> it.  Why should I have to learn a new markup language?
> What the X is Markdown, anyway?
>       
>
>
It is a markup language in roughly the same spirit as the
> previous (Python's reStructuredText) of what you see is what
> you get. This one is more like plaintext mail.
>     
>
>

> I have now read the Markdown documentation.
> It is truly appalling.
>
> Like windmills to Don Quixote? [1]
>
> [1] href="http://en.wikipedia.org/wiki/File:Quixo-panza.jpg">http://en.wikipedia.org/wiki/File:Quixo-panza.jpg
> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From ali.sabil@REDACTED Tue May 31 16:29:45 2011 From: ali.sabil@REDACTED (Ali Sabil) Date: Tue, 31 May 2011 16:29:45 +0200 Subject: [erlang-questions] Best way to integrate QuickCheck and rebar In-Reply-To: References: Message-ID: On Tue, May 31, 2011 at 11:02 AM, Tim Watson wrote: > On 30 May 2011 19:48, Francis Joanis wrote: >> Hi, >> >> I am new to both rebar and QuickCheck and I'm looking for a way to have >> rebar invoke my QuickCheck tests. The only thing I've found so far is to >> have an eunit test invoke QuickCheck from within its test. >> >> What would be the best way to achieve this? > > Embedding your PropEr/QuickCheck tests in eunit and/or common_test > suites is the best thing to do right now, because both these options > afford you test+main code compilation support, code coverage and test > report generation. There is no direct way to run PropEr/QuickCheck > properties with rebar, and whilst it's possible to write a plugin to > do this, there's quite a lot of work involved (take the rebar_eunit > module as an example of what needs to be done). There is a rebar branch with PropEr/QuickCheck support available at: https://github.com/basho/rebar/tree/ta-qc From egil@REDACTED Tue May 31 14:49:53 2011 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Tue, 31 May 2011 14:49:53 +0200 Subject: [erlang-questions] Tool for performace evaluation In-Reply-To: References: <315503444.211231306153617444.JavaMail.root@zimbra> Message-ID: <4DE4E3F1.5060307@erix.ericsson.se> Hi, It all depends on how detailed you want to your information to be. Graphical tools like etop is great to get a feel for how processes are doing in your system but does not get more detailed than that. Eprof: Regarding the profiling guide, it states that *eprof* has "significant slowdown", this is *untrue* and should be revised. *note to self* It has some slowdown, (pulling some data from memory), I would say 2 - 6 times. Eprof also has very low impact on multiple schedulers. Eprof does not produce a callgraph but it will tell you how much time you spend in specific functions which is very helpful. Percept: This application would need some work to be truly useful but it is great to see how saturated your system is. - Getting closer to the metal LCNT: If you have multiprocess scalability problems you can use LCNT (Lock counter) which is a special build of the beam. It is relatively easy to use but you need some basic understanding of thread/lock mechanics and the erlang runtime for the information to be really useful for you. A *great* thing about it LCNT is that process message bottlenecks will be clearly visible, as will any other lock problem. Some problems will be false positives though. GPROF: Also a special build of the beam. This is what I use to get the feel of a specific performance problem i erts or to benchmark a new feature in erts that I've been working on. Gprof will give a callgraph on the erts internals but all erlang code time will obviously wend up in the process_main function in beam_emu. This feature is mostly helpful for erts development but it also might point to some poor programming practices in your code. Using some scripts you can easily get some nice graphs that you with an overview and that you can send to other people: gprof $binary $gmon | gprof2dot.py | dot -Tpng -o $png Regards, Bj?rn-Egil Erlang/OTP On 2011-05-23 14:49, Ahmed Omar wrote: > Your question sounds too vague :) but quick hints : > 1) Monitoring tools : > etop > http://www.erlang.org/doc/man/etop.html > ntop > https://github.com/esl/entop > > 2) Profiling guide > http://www.erlang.org/doc/efficiency_guide/profiling.html > 3) Concurrency profiling tool > http://www.erlang.org/doc/apps/percept/percept_ug.html >> From: "Muhammad Yousaf" >> Is there any tools to evaluate the performance of a module in Erlang that >> can show graphical interface for time elapse, memory usage, performance >> benchmarks etc ?? From watson.timothy@REDACTED Tue May 31 16:51:25 2011 From: watson.timothy@REDACTED (Tim Watson) Date: Tue, 31 May 2011 15:51:25 +0100 Subject: [erlang-questions] Best way to integrate QuickCheck and rebar In-Reply-To: References: Message-ID: > > There is a rebar branch with PropEr/QuickCheck support available at: > https://github.com/basho/rebar/tree/ta-qc > I hadn't seen that one before - thanks for pointing it out. Does anyone know when it's due to be merged? From sverker@REDACTED Tue May 31 15:05:23 2011 From: sverker@REDACTED (Sverker Eriksson) Date: Tue, 31 May 2011 15:05:23 +0200 Subject: [erlang-questions] halfword emulator state In-Reply-To: References: Message-ID: <4DE4E793.1000505@erix.ericsson.se> Paolo Negri wrote: > [...] > - [2] states: "Much more of internal memory structures have been made > able to use "high" memory and are no longer restricted to the 4Gb > limit that still applies for all process heap data." > Is there any documentation explaining exactly which structures can > use the high memory and what instead is constrained to the "low" > memory? Where would the content of the constant pool reside? > > Beam code and Erlang terms are stored in low memory. Except: * ETS table data * Large binaries (>64 bytes) * NIF resources > - How could the containment of structures restricted to the "low" > memory be measured? How would someone monitor the memory usage of the > VM being able to prevent out of memory errors without restricting the > whole VM to use over 4Gb? > > In halfword emulator from R14B03 * erlang:memory() shows a 'low' value counting all allocated low memory. * erlang:system_info(allocator) shows a boolean value 'low' to indicate if an allocator is using low memory or not. > - What are the caveats - if any - for using nifs when using the > halfword emulator? Which aspects of the nifs should be tested in order > to consider safe to run them with the halfword emulator? > > It should be tested on a halfword emulator. A NIF library compiled towards a regular 64-bit vm will fail to load on a halfword vm and vice versa. Don't break the API by assuming anything about the opaque types, such as ERL_NIF_TERM. /Sverker, Erlang/OTP Ericsson From robert.virding@REDACTED Tue May 31 20:06:29 2011 From: robert.virding@REDACTED (Robert Virding) Date: Tue, 31 May 2011 18:06:29 +0000 (GMT) Subject: [erlang-questions] Erlang and Memory management In-Reply-To: <1754771524.242961306865150546.JavaMail.root@zimbra> Message-ID: <1782517589.242981306865189704.JavaMail.root@zimbra> I just want to point out that these rules are BEAM specific and not Erlang specific. So on an implementation with a single heap all data is shared. Now there aren't currently many single heap implementations, to be exact only one, erjang (Erlang on the JVM). :-) Robert ----- "Pierpaolo Bernardi" wrote: > On Tue, May 31, 2011 at 12:09, Roberto Ostinelli > wrote: > > 2011/5/31 Pierpaolo Bernardi > >> > >> This is explained here: > >> > http://www.erlang.org/doc/efficiency_guide/binaryhandling.html#id58893 > >> > > > > I've probably tried to oversimplify my user case. > > > > What happens in case of lists? > > What Gleb said. > > (You can check here: > http://www.erlang.org/doc/efficiency_guide/processes.html#id67714 > if you don't trust Gleb 8^) > > P. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From kostis@REDACTED Tue May 31 20:19:14 2011 From: kostis@REDACTED (Kostis Sagonas) Date: Tue, 31 May 2011 21:19:14 +0300 Subject: [erlang-questions] Erlang and Memory management In-Reply-To: <1782517589.242981306865189704.JavaMail.root@zimbra> References: <1782517589.242981306865189704.JavaMail.root@zimbra> Message-ID: <4DE53122.2020904@cs.ntua.gr> Robert Virding wrote: > I just want to point out that these rules are BEAM specific and not Erlang specific. Well, this is not correct: the BEAM nowhere specifies that its instruction set has to be implemented using a private heap architecture. In fact, we successfully used the BEAM instruction set to implement both a shared heap and a hybrid heap implementation. See: http://user.it.uu.se/~kostis/Papers/heap.pdf > So on an implementation with a single heap all data is shared. Now there aren't currently many single heap implementations, to be exact only one, erjang (Erlang on the JVM). :-) There have been more. We had an OTP system with a shared heap and the hybrid heap system was part of OTP for quite a while. IMO, it's too bad that it was not maintained when Erlang/OTP was extended to support SMP architectures. Also, the ETOS (Erlang to Scheme) system was based on a shared heap architecture. Kostis From pablo.a.meier@REDACTED Tue May 31 21:28:47 2011 From: pablo.a.meier@REDACTED (Paul Meier) Date: Tue, 31 May 2011 12:28:47 -0700 Subject: [erlang-questions] Erlang and Memory management In-Reply-To: <4DE53122.2020904@cs.ntua.gr> References: <1782517589.242981306865189704.JavaMail.root@zimbra> <4DE53122.2020904@cs.ntua.gr> Message-ID: I'm in a similar situation. I've got a few large tries, implemented with gb_trees. I keep them in an orddict, which I'm using as the State variable of a gb_server. For example: ------ init() -> %% State is an orddict of 3 giant Tries, pre-made and fetched from the filesystem. {ok, State}. handle_call({keyed_operation_on_large_data, Key}, _From, State) -> GiantTrie = orddict:find(Key, State), .... computations using GiantTrie.... {reply, Result, State}. I'm finding that my process is crashing due to inability to mmap, and the erl_crash.dump file tells me that the gen_server's supervisor (or, on occasion, the error_logger) is the one with a prohibitively large Stack+Heap. Also, I never modify the Tries or the orddict containing them in calls to the gb_server: it's all read-only. Is storing the value in an orddict, or using regular terms as opposed to binaries causing unnecessary copying? While _I_ know the data is being used in a read-only fashion, is there a place where copying might be occurring because the VM doesn't know this? I was hoping to play with binaries as a next attempt at fixing this (the links in this thread suggest that large binaries are handled more conservatively), but this thread appeared fortuitously, and maybe someone can spot the very likely obvious error that I'm making. I'm grateful for your help, whether in this thread or the others I've enjoyed reading ^_^ -Paul On Tue, May 31, 2011 at 11:19 AM, Kostis Sagonas wrote: > Robert Virding wrote: >> >> I just want to point out that these rules are BEAM specific and not Erlang >> specific. > > Well, this is not correct: the BEAM nowhere specifies that its instruction > set has to be implemented using a private heap architecture. ?In fact, we > successfully used the BEAM instruction set to implement both a shared heap > and a hybrid heap implementation. ?See: > > ?http://user.it.uu.se/~kostis/Papers/heap.pdf > >> So on an implementation with a single heap all data is shared. Now there >> aren't currently many single heap implementations, to be exact only one, >> erjang (Erlang on the JVM). :-) > > There have been more. ?We had an OTP system with a shared heap and the > hybrid heap system was part of OTP for quite a while. ?IMO, it's too bad > that it was not maintained when Erlang/OTP was extended to support SMP > architectures. > > Also, the ETOS (Erlang to Scheme) system was based on a shared heap > architecture. > > Kostis > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From mjtruog@REDACTED Tue May 31 21:37:35 2011 From: mjtruog@REDACTED (Michael Truog) Date: Tue, 31 May 2011 12:37:35 -0700 Subject: [erlang-questions] Erlang and Memory management In-Reply-To: References: <1782517589.242981306865189704.JavaMail.root@zimbra> <4DE53122.2020904@cs.ntua.gr> Message-ID: <4DE5437F.4020201@gmail.com> A better trie data structure exists that should consume less memory, here: https://github.com/okeuday/trie On 05/31/2011 12:28 PM, Paul Meier wrote: > I'm in a similar situation. I've got a few large tries, implemented > with gb_trees. I keep them in an orddict, which I'm using as the > State variable of a gb_server. For example: > > ------ > init() -> > %% State is an orddict of 3 giant Tries, pre-made and fetched from > the filesystem. > {ok, State}. > > handle_call({keyed_operation_on_large_data, Key}, _From, State) -> > GiantTrie = orddict:find(Key, State), > .... computations using GiantTrie.... > {reply, Result, State}. > > I'm finding that my process is crashing due to inability to mmap, and > the erl_crash.dump file tells me that the gen_server's supervisor (or, > on occasion, the error_logger) is the one with a prohibitively large > Stack+Heap. Also, I never modify the Tries or the orddict containing > them in calls to the gb_server: it's all read-only. > > Is storing the value in an orddict, or using regular terms as opposed > to binaries causing unnecessary copying? While _I_ know the data is > being used in a read-only fashion, is there a place where copying > might be occurring because the VM doesn't know this? > > I was hoping to play with binaries as a next attempt at fixing this > (the links in this thread suggest that large binaries are handled more > conservatively), but this thread appeared fortuitously, and maybe > someone can spot the very likely obvious error that I'm making. > > I'm grateful for your help, whether in this thread or the others I've > enjoyed reading ^_^ > > -Paul > > > On Tue, May 31, 2011 at 11:19 AM, Kostis Sagonas wrote: >> Robert Virding wrote: >>> I just want to point out that these rules are BEAM specific and not Erlang >>> specific. >> Well, this is not correct: the BEAM nowhere specifies that its instruction >> set has to be implemented using a private heap architecture. In fact, we >> successfully used the BEAM instruction set to implement both a shared heap >> and a hybrid heap implementation. See: >> >> http://user.it.uu.se/~kostis/Papers/heap.pdf >> >>> So on an implementation with a single heap all data is shared. Now there >>> aren't currently many single heap implementations, to be exact only one, >>> erjang (Erlang on the JVM). :-) >> There have been more. We had an OTP system with a shared heap and the >> hybrid heap system was part of OTP for quite a while. IMO, it's too bad >> that it was not maintained when Erlang/OTP was extended to support SMP >> architectures. >> >> Also, the ETOS (Erlang to Scheme) system was based on a shared heap >> architecture. >> >> Kostis >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From radek.bulat@REDACTED Tue May 31 22:29:35 2011 From: radek.bulat@REDACTED (=?ISO-8859-2?Q?Rados=B3aw_Bu=B3at?=) Date: Tue, 31 May 2011 22:29:35 +0200 Subject: [erlang-questions] dialyzer with -Wbehaviours option Message-ID: When I run dialyzer without any -W* option everything pass. But with -Wbehaviours option I get: $ dialyzer -Wbehaviours -r ebin/ Checking whether the PLT /Users/radarek/.dialyzer_plt is up-to-date... yes Proceeding with analysis... Unknown behaviours (behaviour_info(callbacks) does not return any specs): gen_server (running behaviour_info(callbacks) from shell returns behaviours spec) Dialyzer's plt file has been built with command dialyzer --build_plt --apps kernel stdlib mnesia compiler Do I have to add something to plt or just doing it wrong? -- Pozdrawiam Rados?aw Bu?at http://radarek.jogger.pl - m?j blog From kostis@REDACTED Tue May 31 22:30:56 2011 From: kostis@REDACTED (Kostis Sagonas) Date: Tue, 31 May 2011 23:30:56 +0300 Subject: [erlang-questions] dialyzer with -Wbehaviours option In-Reply-To: References: Message-ID: <4DE55000.2010101@cs.ntua.gr> Rados?aw Bu?at wrote: > When I run dialyzer without any -W* option everything pass. But with > -Wbehaviours option I get: > > $ dialyzer -Wbehaviours -r ebin/ > Checking whether the PLT /Users/radarek/.dialyzer_plt is up-to-date... yes > Proceeding with analysis... > Unknown behaviours (behaviour_info(callbacks) does not return any specs): > gen_server Don't use this option for the time being. It depends on an OTP extension, namely the ability to specify types of callbacks, which has been sitting in 'pu' for more than 8 months now. It has not made it to 'dev', let alone in the release, yet. Once the behaviour modules of OTP will have the necessary information, this option will be safe to use. Kostis From radek.bulat@REDACTED Tue May 31 22:51:14 2011 From: radek.bulat@REDACTED (=?ISO-8859-2?Q?Rados=B3aw_Bu=B3at?=) Date: Tue, 31 May 2011 22:51:14 +0200 Subject: [erlang-questions] dialyzer with -Wbehaviours option In-Reply-To: <4DE55000.2010101@cs.ntua.gr> References: <4DE55000.2010101@cs.ntua.gr> Message-ID: 2011/5/31 Kostis Sagonas : > Don't use this option for the time being. > > It depends on an OTP extension, namely the ability to specify types of > callbacks, which has been sitting in 'pu' for more than 8 months now. It has > not made it to 'dev', let alone in the release, yet. Once the behaviour > modules of OTP will have the necessary information, this option will be safe > to use. Oh, thanks. -- Pozdrawiam Rados?aw Bu?at http://radarek.jogger.pl - m?j blog