From radisb@REDACTED Tue Dec 1 23:28:50 2009 From: radisb@REDACTED (Vassilis Radis) Date: Wed, 2 Dec 2009 00:28:50 +0200 Subject: Trouble with precompiled binaries and USE_DECLSPEC_THREAD Message-ID: The windows binaries available for download are compiled with USE_DECLSPEC_TRHEAD. This, according to the following link: http://msdn.microsoft.com/en-us/library/2s9wt68x.aspx can cause trouble on systems before Vista when using _declspec(thread) compiled modules via LoadLibrary. It did happen to me with the ei libraries, which I needed to use by wrapping them in a dll which was called by .net with LoadLibrary. On windows XP, in order to work with the dll that wrapped the ei libs using LoadLibrary, I needed to recompiled sources with cygwin and remove USE_DECLSPEC_THREAD. On Vista it works out of the box. There is a catch though when recompiling: When you remove the USE_DECLSPEC_THREAD definition from the compiler args, the code fragment that gets included due to the removal (TLS API calls in ei_pthreads.c) contains a call to SwitchToThread which needs . Winbase.h is included in ei.h .But there is something wrong with the include order or the /D compiler definitions order, which causes an unresolved symbol for SwitchToThread() and i had to explicitly re-include winbase.h in ei_pthreads.c I would suggest defining USE_DECLSPEC_THREAD via a test for version (WINVER or WIN32_WINNT or something, i cant remember now). Sorry for not giving more details and maybe provide a patch suggestion, but cygwin got uninstalled and I dont have VC++ on my machine. If you cant reproduce and verify the problem easily please tell me and I will try to get access to VC++ 2005 and reproduce details. Thanks, Vassilis From vinoski@REDACTED Thu Dec 3 16:53:33 2009 From: vinoski@REDACTED (Steve Vinoski) Date: Thu, 3 Dec 2009 10:53:33 -0500 Subject: R12B-05 beam.smp core Message-ID: <65b2728e0912030753k43fe2001i1bb43098bb31b56b@mail.gmail.com> I have a case of R12B-05 beam.smp dumping core on rare occasions on Linux with the traceback below. I've seen it maybe 5 times in 2+ years and have never been able to reproduce it when attempting to debug it. I'm posting it here in the probably slim chance that someone recognizes it and probably even slimmer chance that there's already a patch for it? --steve #0 0x10118414 in offset_heap_ptr () #1 0x1011888c in offset_one_rootset () #2 0x10118738 in offset_rootset () #3 0x10117454 in shrink_new_heap () #4 0x1011384c in minor_collection () #5 0x10111a2c in erts_garbage_collect () #6 0x101117d0 in erts_gc_after_bif_call () #7 0x1014e204 in process_main () #8 0x100a2138 in sched_thread_func () #9 0x101c75f0 in thr_wrapper () #10 0x0fe5481c in start_thread () from /lib/libpthread.so.0 #11 0x0fd8db6c in clone () from /lib/libc.so.6 From zl9d97p02@REDACTED Thu Dec 3 20:32:51 2009 From: zl9d97p02@REDACTED (Simon Cornish) Date: Thu, 3 Dec 2009 11:32:51 -0800 Subject: Fix crash when decoding commercial certificates Message-ID: <21995-1259868771-919078@sneakemail.com> The Erlang ssl application assumes that it is fully aware of all existing extensions, that they are in its list of SSL extensions, and it is able to decode them. However since this is not true commercial certificates containing the id-pe-logotype extension crash the decoder. This is only one example of an extension that the ssl application is unaware of. This patch improves the behaviour by returning the OID tuple and raw extension data for extensions that cannot be decoded. git fetch git://github.com/dotsimon/otp.git ssl_pkix_extensions The attached bare certificate (ie. the BEGIN/END CERTIFICATE lines have been removed) can be used to test the fault and fix as shown: {ok, Bin} = file:read_file("server.bare"). Cert = base64:decode(binary_to_list(Bin)). ssl_pkix:decode_cert(Cert,[ssl]). -------------- next part -------------- A non-text attachment was scrubbed... Name: server.bare Type: application/octet-stream Size: 866 bytes Desc: not available URL: From bgustavsson@REDACTED Thu Dec 3 21:16:18 2009 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Thu, 3 Dec 2009 21:16:18 +0100 Subject: [erlang-bugs] Fix crash when decoding commercial certificates In-Reply-To: <21995-1259868771-919078@sneakemail.com> References: <21995-1259868771-919078@sneakemail.com> Message-ID: <6672d0160912031216q73d39ca6n9c9cd2212026fee5@mail.gmail.com> On Thu, Dec 3, 2009 at 8:32 PM, Simon Cornish wrote: > git fetch git://github.com/dotsimon/otp.git ssl_pkix_extensions Thanks! I have included your branch in 'pu'. There are two minor things that would be nice to fix: 1. Lines in the commit message are very long, so it is difficult to read it in gitk. 2. Your email address does not seem to be configured in your git configuration. Instructions for configuring your user information can now be found at the beginning of: http://wiki.github.com/erlang/otp/submitting-patches If it is OK, I can break the lines in the commit message and replace that local email address with the email that you have subscribed to this list with. -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From dgud@REDACTED Fri Dec 4 08:41:00 2009 From: dgud@REDACTED (Dan Gudmundsson) Date: Fri, 4 Dec 2009 08:41:00 +0100 Subject: [erlang-bugs] Fix crash when decoding commercial certificates In-Reply-To: <6672d0160912031216q73d39ca6n9c9cd2212026fee5@mail.gmail.com> References: <21995-1259868771-919078@sneakemail.com> <6672d0160912031216q73d39ca6n9c9cd2212026fee5@mail.gmail.com> Message-ID: <93df43b60912032341w6be9abebx9c309b71a3a64954@mail.gmail.com> Hmm, you should use the public_key application, though it is rather undocumented :-) The ssl_pkix module should not be used anymore. Patches on (or documentation of) the public_key application would be great. I don't know if I like the idea of continuing patching ssl_pkix.erl, that will lead to more usage of a module we want to phase out. /Dan 2009/12/3 Bj?rn Gustavsson : > On Thu, Dec 3, 2009 at 8:32 PM, Simon Cornish wrote: >> git fetch git://github.com/dotsimon/otp.git ssl_pkix_extensions > > Thanks! I have included your branch in 'pu'. > > There are two minor things that would be nice to fix: > > 1. Lines in the commit message are very long, so it is difficult to > read it in gitk. > > 2. Your email address does not seem to be configured in your git configuration. > > Instructions for configuring your user information can now be found > at the beginning of: > > http://wiki.github.com/erlang/otp/submitting-patches > > If it is OK, I can break the lines in the commit message and replace > that local email address with the email that you have subscribed to this > list with. > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB > > ________________________________________________________________ > erlang-bugs mailing list. See http://www.erlang.org/faq.html > erlang-bugs (at) erlang.org > > From kenneth.lundin@REDACTED Fri Dec 4 13:52:53 2009 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Fri, 4 Dec 2009 13:52:53 +0100 Subject: [erlang-bugs] asn1ct out of date? In-Reply-To: <4AF6E60C.5020608@gmail.com> References: <4AF6E60C.5020608@gmail.com> Message-ID: Hi, This isa new LDAP ASN.1 spec that I have not seen before. The previous ones has passed the Erlang ASN.1 compiler without problems. The Erlang ASN.1 compiler does not support everything in the 2002 standard of ASN.1 and there might also be limitations vs the 1997 standard. We have implemented the constructs that we have seen need for because they have occured in specifications used by our customers. This is the firs time I see use of: EXSTENSIBILITY IMPLIED, % I will implement that soon, quite easy SEQUENCE OF NamedType which is equivalent to SEQUENCE OF identifier Type % I will implement that too,the identifier is of no real use as I understand it except maybe if the XML encoding rules and value notation is to be used. And we don't support them now. SET OF identifier Type % will implement that too, same as SEQUENCE OF SEQUENCE SIZE (1..MAX) OF uri URI % I can't see that this is allowed syntax in any version of ASN.1? /Kenneth , Erlang/OTP Ericsson On Sun, Nov 8, 2009 at 4:38 PM, Steve Davis wrote: > While working towards implementing an LDAP server I found that asn1ct does > not appear to support the current LDAP asn.1 specification format. > > http://tools.ietf.org/html/rfc4511#appendix-B > > Attached is the modified ASN.1 for LDAP3 with the statements that cause the > compile time errors commented out as: --## > > Of course, the modified asn file defines a protocol that is no longer > "according to spec" > > /s > > --## Lightweight-Directory-Access-Protocol-V3 {1 3 6 1 1 18} > -- Copyright (C) The Internet Society (2006). ?This version of > -- this ASN.1 module is part of RFC 4511; see the RFC itself > -- for full legal notices. > LDAP3 > DEFINITIONS > IMPLICIT TAGS > --## EXTENSIBILITY IMPLIED > > ::= > > BEGIN > > LDAPMessage ::= SEQUENCE { > ? ? messageID ? ? ? MessageID, > ? ? protocolOp ? ? ?CHOICE { > ? ? ? ? ?bindRequest ? ? ? ? ? BindRequest, > ? ? ? ? ?bindResponse ? ? ? ? ?BindResponse, > ? ? ? ? ?unbindRequest ? ? ? ? UnbindRequest, > ? ? ? ? ?searchRequest ? ? ? ? SearchRequest, > ? ? ? ? ?searchResEntry ? ? ? ?SearchResultEntry, > ? ? ? ? ?searchResDone ? ? ? ? SearchResultDone, > ? ? ? ? ?searchResRef ? ? ? ? ?SearchResultReference, > ? ? ? ? ?modifyRequest ? ? ? ? ModifyRequest, > ? ? ? ? ?modifyResponse ? ? ? ?ModifyResponse, > ? ? ? ? ?addRequest ? ? ? ? ? ?AddRequest, > ? ? ? ? ?addResponse ? ? ? ? ? AddResponse, > ? ? ? ? ?delRequest ? ? ? ? ? ?DelRequest, > ? ? ? ? ?delResponse ? ? ? ? ? DelResponse, > ? ? ? ? ?modDNRequest ? ? ? ? ?ModifyDNRequest, > ? ? ? ? ?modDNResponse ? ? ? ? ModifyDNResponse, > ? ? ? ? ?compareRequest ? ? ? ?CompareRequest, > ? ? ? ? ?compareResponse ? ? ? CompareResponse, > ? ? ? ? ?abandonRequest ? ? ? ?AbandonRequest, > ? ? ? ? ?extendedReq ? ? ? ? ? ExtendedRequest, > ? ? ? ? ?extendedResp ? ? ? ? ?ExtendedResponse, > ? ? ? ? ?..., > ? ? ? ? ?intermediateResponse ?IntermediateResponse }, > ? ? controls ? ? ? [0] Controls OPTIONAL } > > MessageID ::= INTEGER (0 .. ?maxInt) > > maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- > > LDAPString ::= OCTET STRING -- UTF-8 encoded, > ? ? ? ? ? ? ? ? ? ? ? ? ? ?-- [ISO10646] characters > > LDAPOID ::= OCTET STRING -- Constrained to > ? ? ? ? ? ? ? ? ? ? ? ? -- [RFC4512] > > LDAPDN ::= LDAPString -- Constrained to > ? ? ? ? ? ? ? ? ? ? ?-- [RFC4514] > > RelativeLDAPDN ::= LDAPString -- Constrained to > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?-- [RFC4514] > > AttributeDescription ::= LDAPString > ? ? ? ? ? ? ? ? ? ? ? ?-- Constrained to > ? ? ? ? ? ? ? ? ? ? ? ?-- [RFC4512] > > AttributeValue ::= OCTET STRING > > AttributeValueAssertion ::= SEQUENCE { > ? ? attributeDesc ? AttributeDescription, > ? ? assertionValue ?AssertionValue } > > AssertionValue ::= OCTET STRING > > PartialAttribute ::= SEQUENCE { > ? ? type ? ? ? AttributeDescription, > --## ? ? vals ? ? ? SET OF value AttributeValue } > ? ? vals ? ? ? SET OF AttributeValue } > > Attribute ::= PartialAttribute(WITH COMPONENTS { > ? ? ..., > ? ? vals (SIZE(1..MAX))}) > > MatchingRuleId ::= LDAPString > > LDAPResult ::= SEQUENCE { > ? ? resultCode ? ? ? ? ENUMERATED { > ? ? ? ? ?success ? ? ? ? ? ? ? ? ? ? ?(0), > ? ? ? ? ?operationsError ? ? ? ? ? ? ?(1), > ? ? ? ? ?protocolError ? ? ? ? ? ? ? ?(2), > ? ? ? ? ?timeLimitExceeded ? ? ? ? ? ?(3), > ? ? ? ? ?sizeLimitExceeded ? ? ? ? ? ?(4), > ? ? ? ? ?compareFalse ? ? ? ? ? ? ? ? (5), > ? ? ? ? ?compareTrue ? ? ? ? ? ? ? ? ?(6), > ? ? ? ? ?authMethodNotSupported ? ? ? (7), > ? ? ? ? ?strongerAuthRequired ? ? ? ? (8), > ? ? ? ? ? ? ? -- 9 reserved -- > ? ? ? ? ?referral ? ? ? ? ? ? ? ? ? ? (10), > ? ? ? ? ?adminLimitExceeded ? ? ? ? ? (11), > ? ? ? ? ?unavailableCriticalExtension (12), > ? ? ? ? ?confidentialityRequired ? ? ?(13), > ? ? ? ? ?saslBindInProgress ? ? ? ? ? (14), > ? ? ? ? ? ? ? -- 15??? -- > ? ? ? ? ?noSuchAttribute ? ? ? ? ? ? ?(16), > ? ? ? ? ?undefinedAttributeType ? ? ? (17), > ? ? ? ? ?inappropriateMatching ? ? ? ?(18), > ? ? ? ? ?constraintViolation ? ? ? ? ?(19), > ? ? ? ? ?attributeOrValueExists ? ? ? (20), > ? ? ? ? ?invalidAttributeSyntax ? ? ? (21), > ? ? ? ? ? ? ? -- 22-31 unused -- > ? ? ? ? ?noSuchObject ? ? ? ? ? ? ? ? (32), > ? ? ? ? ?aliasProblem ? ? ? ? ? ? ? ? (33), > ? ? ? ? ?invalidDNSyntax ? ? ? ? ? ? ?(34), > ? ? ? ? ? ? ? -- 35 reserved for undefined isLeaf -- > ? ? ? ? ?aliasDereferencingProblem ? ?(36), > ? ? ? ? ? ? ? -- 37-47 unused -- > ? ? ? ? ?inappropriateAuthentication ?(48), > ? ? ? ? ?invalidCredentials ? ? ? ? ? (49), > ? ? ? ? ?insufficientAccessRights ? ? (50), > ? ? ? ? ?busy ? ? ? ? ? ? ? ? ? ? ? ? (51), > ? ? ? ? ?unavailable ? ? ? ? ? ? ? ? ?(52), > ? ? ? ? ?unwillingToPerform ? ? ? ? ? (53), > ? ? ? ? ?loopDetect ? ? ? ? ? ? ? ? ? (54), > ? ? ? ? ? ? ? -- 55-63 unused -- > ? ? ? ? ?namingViolation ? ? ? ? ? ? ?(64), > ? ? ? ? ?objectClassViolation ? ? ? ? (65), > ? ? ? ? ?notAllowedOnNonLeaf ? ? ? ? ?(66), > ? ? ? ? ?notAllowedOnRDN ? ? ? ? ? ? ?(67), > ? ? ? ? ?entryAlreadyExists ? ? ? ? ? (68), > ? ? ? ? ?objectClassModsProhibited ? ?(69), > ? ? ? ? ? ? ? -- 70 reserved for CLDAP -- > ? ? ? ? ?affectsMultipleDSAs ? ? ? ? ?(71), > ? ? ? ? ? ? ? -- 72-79 unused -- > ? ? ? ? ?other ? ? ? ? ? ? ? ? ? ? ? ?(80) > --## ? ? ? ? ... > ? ? ? ? ?}, > ? ? matchedDN ? ? ? ? ?LDAPDN, > ? ? diagnosticMessage ?LDAPString, > ? ? referral ? ? ? ? ? [3] Referral OPTIONAL } > > --## Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI > Referral ::= SEQUENCE OF URI > > URI ::= LDAPString ? ? -- limited to characters permitted in > ? ? ? ? ? ? ? ? ? ? ? -- URIs > > --## Controls ::= SEQUENCE OF control Control > Controls ::= SEQUENCE OF Control > > Control ::= SEQUENCE { > ? ? controlType ? ? ? ? ? ? LDAPOID, > ? ? criticality ? ? ? ? ? ? BOOLEAN DEFAULT FALSE, > ? ? controlValue ? ? ? ? ? ?OCTET STRING OPTIONAL } > > BindRequest ::= [APPLICATION 0] SEQUENCE { > ? ? version ? ? ? ? ? ? ? ? INTEGER (1 .. ?127), > ? ? name ? ? ? ? ? ? ? ? ? ?LDAPDN, > ? ? authentication ? ? ? ? ?AuthenticationChoice } > > AuthenticationChoice ::= CHOICE { > ? ? simple ? ? ? ? ? ? ? ? ?[0] OCTET STRING, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? -- 1 and 2 reserved > ? ? sasl ? ? ? ? ? ? ? ? ? ?[3] SaslCredentials, > ? ? ... ?} > > SaslCredentials ::= SEQUENCE { > ? ? mechanism ? ? ? ? ? ? ? LDAPString, > ? ? credentials ? ? ? ? ? ? OCTET STRING OPTIONAL } > > BindResponse ::= [APPLICATION 1] SEQUENCE { > ? ? COMPONENTS OF LDAPResult, > ? ? serverSaslCreds ? ?[7] OCTET STRING OPTIONAL } > > UnbindRequest ::= [APPLICATION 2] NULL > > SearchRequest ::= [APPLICATION 3] SEQUENCE { > ? ? baseObject ? ? ?LDAPDN, > ? ? scope ? ? ? ? ? ENUMERATED { > ? ? ? ? ?baseObject ? ? ? ? ? ? ?(0), > ? ? ? ? ?singleLevel ? ? ? ? ? ? (1), > ? ? ? ? ?wholeSubtree ? ? ? ? ? ?(2), > ? ? ? ? ?... ?}, > ? ? derefAliases ? ?ENUMERATED { > ? ? ? ? ?neverDerefAliases ? ? ? (0), > ? ? ? ? ?derefInSearching ? ? ? ?(1), > ? ? ? ? ?derefFindingBaseObj ? ? (2), > ? ? ? ? ?derefAlways ? ? ? ? ? ? (3) }, > ? ? sizeLimit ? ? ? INTEGER (0 .. ?maxInt), > ? ? timeLimit ? ? ? INTEGER (0 .. ?maxInt), > ? ? typesOnly ? ? ? BOOLEAN, > ? ? filter ? ? ? ? ?Filter, > ? ? attributes ? ? ?AttributeSelection } > > --## AttributeSelection ::= SEQUENCE OF selector LDAPString > AttributeSelection ::= SEQUENCE OF LDAPString > ? ? ? ? ? ? ? -- The LDAPString is constrained to > ? ? ? ? ? ? ? -- in Section 4.5.1.8 > > Filter ::= CHOICE { > --## ? ? and ? ? ? ? ? ? [0] SET SIZE (1..MAX) OF filter Filter, > --## ? ? or ? ? ? ? ? ? ?[1] SET SIZE (1..MAX) OF filter Filter, > ? ? and ? ? ? ? ? ? [0] SET OF Filter, > ? ? or ? ? ? ? ? ? ?[1] SET OF Filter, > ? ? not ? ? ? ? ? ? [2] Filter, > ? ? equalityMatch ? [3] AttributeValueAssertion, > ? ? substrings ? ? ?[4] SubstringFilter, > ? ? greaterOrEqual ?[5] AttributeValueAssertion, > ? ? lessOrEqual ? ? [6] AttributeValueAssertion, > ? ? present ? ? ? ? [7] AttributeDescription, > ? ? approxMatch ? ? [8] AttributeValueAssertion, > ? ? extensibleMatch [9] MatchingRuleAssertion, > ? ? ... ?} > > SubstringFilter ::= SEQUENCE { > ? ? type ? ? ? ? ? AttributeDescription, > --## ? ? substrings ? ? SEQUENCE SIZE (1..MAX) OF substring CHOICE { > ? ? substrings ? ? SEQUENCE OF CHOICE { > ? ? ? ? ?initial [0] AssertionValue, ?-- can occur at most once > ? ? ? ? ?any ? ? [1] AssertionValue, > ? ? ? ? ?final ? [2] AssertionValue } -- can occur at most once > ? ? } > > MatchingRuleAssertion ::= SEQUENCE { > ? ? matchingRule ? ?[1] MatchingRuleId OPTIONAL, > ? ? type ? ? ? ? ? ?[2] AttributeDescription OPTIONAL, > ? ? matchValue ? ? ?[3] AssertionValue, > ? ? dnAttributes ? ?[4] BOOLEAN DEFAULT FALSE } > > SearchResultEntry ::= [APPLICATION 4] SEQUENCE { > ? ? objectName ? ? ?LDAPDN, > ? ? attributes ? ? ?PartialAttributeList } > > PartialAttributeList ::= SEQUENCE OF PartialAttribute > --## ? ? ? ? ? ? ? ? ? ? partialAttribute PartialAttribute > > SearchResultReference ::= [APPLICATION 19] SEQUENCE OF URI > --## ? ? ? ? ? ? ? ? ? ? ? ? ?SIZE (1..MAX) OF uri URI > > SearchResultDone ::= [APPLICATION 5] LDAPResult > > ModifyRequest ::= [APPLICATION 6] SEQUENCE { > ? ? object ? ? ? ? ?LDAPDN, > --## ? ? changes ? ? ? ? SEQUENCE OF change SEQUENCE { > ? ? changes ? ? ? ? SEQUENCE OF SEQUENCE { > ? ? ? ? ?operation ? ? ? ENUMERATED { > ? ? ? ? ? ? ? add ? ? (0), > ? ? ? ? ? ? ? delete ?(1), > ? ? ? ? ? ? ? replace (2), > ? ? ? ? ? ? ? ... ?}, > ? ? ? ? ?modification ? ?PartialAttribute } } > > ModifyResponse ::= [APPLICATION 7] LDAPResult > > AddRequest ::= [APPLICATION 8] SEQUENCE { > ? ? entry ? ? ? ? ? LDAPDN, > ? ? attributes ? ? ?AttributeList } > > --## AttributeList ::= SEQUENCE OF attribute Attribute > AttributeList ::= SEQUENCE OF Attribute > > AddResponse ::= [APPLICATION 9] LDAPResult > > DelRequest ::= [APPLICATION 10] LDAPDN > > DelResponse ::= [APPLICATION 11] LDAPResult > > ModifyDNRequest ::= [APPLICATION 12] SEQUENCE { > ? ? entry ? ? ? ? ? LDAPDN, > ? ? newrdn ? ? ? ? ?RelativeLDAPDN, > ? ? deleteoldrdn ? ?BOOLEAN, > ? ? newSuperior ? ? [0] LDAPDN OPTIONAL } > > ModifyDNResponse ::= [APPLICATION 13] LDAPResult > > CompareRequest ::= [APPLICATION 14] SEQUENCE { > ? ? entry ? ? ? ? ? LDAPDN, > ? ? ava ? ? ? ? ? ? AttributeValueAssertion } > > CompareResponse ::= [APPLICATION 15] LDAPResult > > AbandonRequest ::= [APPLICATION 16] MessageID > > ExtendedRequest ::= [APPLICATION 23] SEQUENCE { > ? ? requestName ? ? ?[0] LDAPOID, > ? ? requestValue ? ? [1] OCTET STRING OPTIONAL } > > ExtendedResponse ::= [APPLICATION 24] SEQUENCE { > ? ? COMPONENTS OF LDAPResult, > ? ? responseName ? ? [10] LDAPOID OPTIONAL, > ? ? responseValue ? ?[11] OCTET STRING OPTIONAL } > > IntermediateResponse ::= [APPLICATION 25] SEQUENCE { > ? ? responseName ? ? [0] LDAPOID OPTIONAL, > ? ? responseValue ? ?[1] OCTET STRING OPTIONAL } > > END > > > ________________________________________________________________ > erlang-bugs mailing list. See http://www.erlang.org/faq.html > erlang-bugs (at) erlang.org > From kenneth.lundin@REDACTED Tue Dec 8 22:39:56 2009 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Tue, 8 Dec 2009 22:39:56 +0100 Subject: [erlang-bugs] asn1ct out of date? In-Reply-To: References: <4AF6E60C.5020608@gmail.com> Message-ID: Hi again, I was a bit quick in the last answer regarding the SEQUENCE SIZE() OF construct. This construct is already supported, but not the NamedType following the OF keyword. This is the same limitation as the plain SEQUENCE OF which also did not support NamedType. By the way thanks for the bug-report. I will correct and add this functionality in the next release. I also think that your changes in the ASN.1 spec in order to let it through the compiler is perfectly ok because they will have no impact on the BER encoding (which is used in LDAP). /Kenneth On Fri, Dec 4, 2009 at 1:52 PM, Kenneth Lundin wrote: > Hi, > > This isa new LDAP ASN.1 spec that I have not seen before. > The previous ones has passed the Erlang ASN.1 compiler without problems. > > The Erlang ASN.1 compiler does not support everything in the 2002 > standard of ASN.1 and there might also be limitations vs the 1997 > standard. > > We have implemented the constructs that we have seen need for because > they have occured in specifications used by our customers. > > This is the firs time I see use of: > > EXSTENSIBILITY IMPLIED, % I will implement that ?soon, quite easy > SEQUENCE OF NamedType which is equivalent to > SEQUENCE OF identifier Type % I will implement that too,the > identifier is of no real use as I understand it except maybe if the > XML encoding rules and value notation is to be used. And > we don't support them now. > > SET OF identifier Type % will implement that too, same as SEQUENCE OF > > SEQUENCE SIZE (1..MAX) OF uri URI % I can't see that this is allowed > syntax in any version of ASN.1? > > /Kenneth , Erlang/OTP Ericsson > > On Sun, Nov 8, 2009 at 4:38 PM, Steve Davis > wrote: >> While working towards implementing an LDAP server I found that asn1ct does >> not appear to support the current LDAP asn.1 specification format. >> >> http://tools.ietf.org/html/rfc4511#appendix-B >> >> Attached is the modified ASN.1 for LDAP3 with the statements that cause the >> compile time errors commented out as: --## >> >> Of course, the modified asn file defines a protocol that is no longer >> "according to spec" >> From steven.charles.davis@REDACTED Wed Dec 9 01:16:27 2009 From: steven.charles.davis@REDACTED (Steve Davis) Date: Tue, 08 Dec 2009 18:16:27 -0600 Subject: [erlang-bugs] asn1ct out of date? In-Reply-To: References: <4AF6E60C.5020608@gmail.com> Message-ID: <4B1EEC5B.7050205@gmail.com> Hi Kenneth, Thanks for your complete and excellent response to this issue. I'm most impressed by you and also by your team. (btw the github move, the beta website, and doc searching is all truly spectacular and highly appreciated) Best regards, Steve Kenneth Lundin wrote: > Hi again, > > I was a bit quick in the last answer regarding the SEQUENCE SIZE() OF construct. > This construct is already supported, but not the NamedType following > the OF keyword. > This is the same limitation as the plain SEQUENCE OF which also did > not support NamedType. > > By the way thanks for the bug-report. > I will correct and add this functionality in the next release. > > I also think that your changes in the ASN.1 spec in order to let it > through the compiler is > perfectly ok because they will have no impact on the BER encoding > (which is used in LDAP). > > /Kenneth > > On Fri, Dec 4, 2009 at 1:52 PM, Kenneth Lundin wrote: >> Hi, >> >> This isa new LDAP ASN.1 spec that I have not seen before. >> The previous ones has passed the Erlang ASN.1 compiler without problems. >> >> The Erlang ASN.1 compiler does not support everything in the 2002 >> standard of ASN.1 and there might also be limitations vs the 1997 >> standard. >> >> We have implemented the constructs that we have seen need for because >> they have occured in specifications used by our customers. >> >> This is the firs time I see use of: >> >> EXSTENSIBILITY IMPLIED, % I will implement that soon, quite easy >> SEQUENCE OF NamedType which is equivalent to >> SEQUENCE OF identifier Type % I will implement that too,the >> identifier is of no real use as I understand it except maybe if the >> XML encoding rules and value notation is to be used. And >> we don't support them now. >> >> SET OF identifier Type % will implement that too, same as SEQUENCE OF >> >> SEQUENCE SIZE (1..MAX) OF uri URI % I can't see that this is allowed >> syntax in any version of ASN.1? >> >> /Kenneth , Erlang/OTP Ericsson >> >> On Sun, Nov 8, 2009 at 4:38 PM, Steve Davis >> wrote: >>> While working towards implementing an LDAP server I found that asn1ct does >>> not appear to support the current LDAP asn.1 specification format. >>> >>> http://tools.ietf.org/html/rfc4511#appendix-B >>> >>> Attached is the modified ASN.1 for LDAP3 with the statements that cause the >>> compile time errors commented out as: --## >>> >>> Of course, the modified asn file defines a protocol that is no longer >>> "according to spec" >>> > From hynek@REDACTED Wed Dec 9 13:28:39 2009 From: hynek@REDACTED (Hynek Vychodil) Date: Wed, 9 Dec 2009 13:28:39 +0100 Subject: Bug in documentation In-Reply-To: <4d08db370911241200r6c4a9c3ak8485eb7a3e3b58cc@mail.gmail.com> References: <4d08db370911241200r6c4a9c3ak8485eb7a3e3b58cc@mail.gmail.com> Message-ID: <4d08db370912090428i55f89336y6ead1e599ca4e776@mail.gmail.com> Hello, There is misplaced paragraph in http://www.erlang.org/doc/man/erlang.html process_flag(save_calls, N) ? ? ? When there are runnable processes on priority max no processes on priority low, normal, or high will be selected for execution. As with the high priority, processes on lower priorities might execute in parallel with processes on priority max. Paragraph startin "When there are ..." should be placed above `process_flag(save_calls, N)` because it belongs to `process_flag(priority, Level)` above. With best regards -- --Hynek (Pichi) Vychodil From zl9d97p02@REDACTED Thu Dec 10 13:12:00 2009 From: zl9d97p02@REDACTED (Simon Cornish) Date: Thu, 10 Dec 2009 13:12:00 +0100 Subject: internal compiler faults Message-ID: <4816-1260447151-444331@sneakemail.com> Hi, I was trying to refine some code (that I can't publish) that threw this error on compilation: xxx: function make_content_list/6+108: Internal consistency check failed - please report this bug. Instruction: {move,{y,0},{x,0}} Error: {unassigned,{y,0}}: And instead I get something different with the attached module using two variants of more or less the same code from the first error: d124:test_server simon$ erlc -W ~/tmp/a1.erl Function: bad/3 /Users/simon/tmp/a1.erl:none: internal error in beam_bool; crash reason: {{case_clause, {'EXIT', {function_clause, [{gb_trees,get_1,[{tmp,0},nil]}, {beam_bool,bopt_good_arg,2}, {beam_bool,bopt_good_args,2}, {beam_bool,bopt_tree,3}, {beam_bool,bopt_tree,3}, {beam_bool,bopt_tree_cg,3}, {beam_bool,bopt_block,5}, {beam_bool,bopt,3}]}}}, [{compile,'-select_passes/2-anonymous-2-',2}, {compile,'-internal_comp/4-anonymous-1-',2}, {compile,fold_comp,3}, {compile,internal_comp,4}, {compile,internal,3}]} Build is http://github.com/erlang/otp/tree/ee51ffa886cdbc7a577d6e068236c107f0137696 (a few behind on ccase/r13b04_dev), host is OSX 10.6 (32-bit kernel) built with --enable-darwin-64bit Any hints on debugging/fixing the first error will also be appreciated. /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: a1.erl Type: application/octet-stream Size: 520 bytes Desc: not available URL: From kostis@REDACTED Thu Dec 10 14:05:37 2009 From: kostis@REDACTED (Kostis Sagonas) Date: Thu, 10 Dec 2009 15:05:37 +0200 Subject: [erlang-bugs] internal compiler faults In-Reply-To: <4816-1260447151-444331@sneakemail.com> References: <4816-1260447151-444331@sneakemail.com> Message-ID: <4B20F221.9040007@cs.ntua.gr> Simon Cornish wrote: > Hi, > I was trying to refine some code (that I can't publish) that threw > this error on compilation: > > xxx: function make_content_list/6+108: > Internal consistency check failed - please report this bug. > Instruction: {move,{y,0},{x,0}} > Error: {unassigned,{y,0}}: This error might or might not be the same as the one the program you attached in your previous mail is suffering from (function clause exception in gb_trees:get/1) -- we'll never know if you do not show us the code. Please try to minimize it so that it shows the same internal consistency problem as above -- minimizing it not only saves time for the compiler maintainer but it also makes sure that the program will be useful to no one other than the compiler writers -- and send it here. > And instead I get something different with the attached module using > two variants of more or less the same code from the first error: For Bjorn, I guess, I include a smaller version of your module that also throws the same error as the program you attached. Function: bad/3 /home/kostis/a1.erl:none: internal error in beam_bool; crash reason: {{case_clause, {'EXIT', {function_clause, [{gb_trees,get_1,[{tmp,0},nil]}, {lists,mapfoldl,3}]}}}, > Any hints on debugging/fixing the first error will also be appreciated. You've not shown us the problematic code so it's very hard to know what's happening, but here is some educated guess on how to bypass it: Your program has the following construct: Var = BOOLEAN_EXPR, if Var == true; Var == false,OTHER_TESTS -> ... Change this to either: Var = BOOLEAN_EXPR, if Var == true orelse Var == false,OTHER_TESTS -> ... or to simply: Var = BOOLEAN_EXPR, if Var == true; OTHER_TESTS -> ... Kostis -------------- next part -------------- A non-text attachment was scrubbed... Name: a1.erl Type: text/x-erlang Size: 197 bytes Desc: not available URL: From bgustavsson@REDACTED Thu Dec 10 22:37:52 2009 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Thu, 10 Dec 2009 22:37:52 +0100 Subject: [erlang-bugs] internal compiler faults In-Reply-To: <4B20F221.9040007@cs.ntua.gr> References: <4816-1260447151-444331@sneakemail.com> <4B20F221.9040007@cs.ntua.gr> Message-ID: <6672d0160912101337q370f92a2o5e5bf5d186a6f824@mail.gmail.com> On Thu, Dec 10, 2009 at 2:05 PM, Kostis Sagonas wrote: > For Bjorn, I guess, I include a smaller version of your module that also > throws the same error as the program you attached. Thanks for minimizing the example. I have included a fix in the 'pu' branch. Basically, my fix just treats the symptom (disabling the optimization for that kind of code instead of crashing), but I have looked at the code to understand why it crashed and added some information about it to the comments and commit message. To debug problems found by the beam_validator, I generally start by disabling various optimization passes to see if the problem disappears. If it does, I know in which part of the code to start looking. Type compile:options() in the shell to get a list of the compiler options (the one with the explanation "Skip..." are the ones you are interested in). -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From sgolovan@REDACTED Fri Dec 11 14:52:00 2009 From: sgolovan@REDACTED (Sergei Golovan) Date: Fri, 11 Dec 2009 16:52:00 +0300 Subject: Building docs for R13B-03 fails Message-ID: Hi! I'm trying to build Erlang documentation from the sources (the goal is to switch from prebuilt docs for Debian Erlang packages as building them from the source is preferable). To do that I run make make TYPE=docs (in fact, make libs doesn't recognize TYPE, so I had to replace "make opt" by "make $(TYPE) in the top-level Makefile). and I've found several problems which make build fail: 1) For some XML files (e.g. erts/docs/src/book.xml) xsltproc reports runtime errors about undefined variables (partnum in line 871 and 963 of db_pdf.xsl, in lines 1075 and 1173 of db_html.xsl). Is this a bug in the stylesheets or in xsltproc? (Both 1.1.24 from Debian stable and 1.1.26 from Debian unstable failed.) 2) wx application has duplicated targets html and docs in its makefile. 3) wx application (and others too) require docb_gen script to generate XML docs sources. It is missing. (I suppose that it is a simple wrapper around docb_gen Erlang module and could be recreated, but It'd be better if it were shipped in Erlang sources.) Is Erlang documentation supposed to be buildable from the source, or it still requires some unavailable tools? Cheers! -- Sergei Golovan From zl9d97p02@REDACTED Fri Dec 11 15:20:49 2009 From: zl9d97p02@REDACTED (Simon Cornish) Date: Fri, 11 Dec 2009 15:20:49 +0100 Subject: [erlang-bugs] internal compiler faults In-Reply-To: <6672d0160912101337q370f92a2o5e5bf5d186a6f824@mail.gmail.com> References: <4816-1260447151-444331@sneakemail.com> <4B20F221.9040007@cs.ntua.gr> <6672d0160912101337q370f92a2o5e5bf5d186a6f824@mail.gmail.com> Message-ID: <3299-1260541253-694178@sneakemail.com> Hi Bj?rn, Thanks for your quick patch. 2009/12/10 Bj?rn Gustavsson bgustavsson-at-gmail.com wrote: > On Thu, Dec 10, 2009 at 2:05 PM, Kostis Sagonas wrote: >> For Bjorn, I guess, I include a smaller version of your module that also >> throws the same error as the program you attached. > > Thanks for minimizing the example. I fail to see how this minimisation helps the discussion. The point of including both the yes/3 and bad/3 functions was to show that only one of the two different methods of calculating Do1 & Do2 caused the crash. I would have thought this would help point to the underlying optimisation error. Regarding the internal consistency check, I used the beam_bool patch and still encountered the same problem. Attached is a small example. It will compile if no_bopt is used. It will also compile if the boolean guard is not repeated (eg. CH2 is assigned a constant value). On Thu, Dec 10, 2009 at 2:05 PM, Kostis Sagonas wrote: [...] > we'll never know if you do not show us the code. Yes, it is self-evident that the code that produces an error is preferable for solving that problem than different code that produces a different error. Regards, Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: a2.erl Type: application/octet-stream Size: 344 bytes Desc: not available URL: From bgustavsson@REDACTED Fri Dec 11 16:38:35 2009 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Fri, 11 Dec 2009 16:38:35 +0100 Subject: [erlang-bugs] internal compiler faults In-Reply-To: <3299-1260541253-694178@sneakemail.com> References: <4816-1260447151-444331@sneakemail.com> <4B20F221.9040007@cs.ntua.gr> <6672d0160912101337q370f92a2o5e5bf5d186a6f824@mail.gmail.com> <3299-1260541253-694178@sneakemail.com> Message-ID: <6672d0160912110738q6aeee2bfra08e05863b6839b8@mail.gmail.com> On Fri, Dec 11, 2009 at 3:20 PM, Simon Cornish wrote: > I fail to see how this minimisation helps the discussion. The point of > including both the yes/3 and bad/3 functions was to show that only one > of the two different methods of calculating Do1 & Do2 caused the > crash. I would have thought this would help point to the underlying > optimisation error. It helped me. I generally debug optimization problems by printing out and inspecting the internal data structures, so the smaller the better. Having different versions to compare can be useful, however, when I have located the problem and I need to decide the best way to solve it. > Regarding the internal consistency check, I used the beam_bool patch > and still encountered the same problem. Attached is a small example. > It will compile if no_bopt is used. It will also compile if the > boolean guard is not repeated (eg. CH2 is assigned a constant value). Thanks! That information gives me a pretty good idea where I should start looking for the problem. -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From matthew@REDACTED Fri Dec 11 17:11:19 2009 From: matthew@REDACTED (Matthew Sackman) Date: Fri, 11 Dec 2009 16:11:19 +0000 Subject: Cover blows up on parsing binary comprehension Message-ID: <20091211161119.GA598@wellquite.org> -module(foo). -export([f/0, g/1]). f() -> cover:start(), {ok,foo} = cover:compile_module(foo). g(SeqIds) -> << <<3:2, SeqId:62>> || SeqId <- SeqIds >>. $ erlc -Wall -v +debug_info foo.erl $ erl Erlang R13B03 (erts-5.7.4) [source] [64-bit] [smp:4:4] [rq:4] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.7.4 (abort with ^G) 1> foo:f(). =ERROR REPORT==== 11-Dec-2009::16:10:15 === Error in process <0.35.0> with exit value: {{badmatch,{bin,9,[{bin_element,9,{integer,9,3},{integer,9,2},default},{bin_element,9,{var,9,'SeqId'},{integer,9,62},default}]}},[{cover,munge_expr,2},{cover,munge_body,4},{cover,munge_clauses,4},{cover,munge,4},{cover,transform_2... ** exception exit: {{badmatch,{bin,9, [{bin_element,9,{integer,9,3},{integer,9,2},default}, {bin_element,9,{var,9,'SeqId'},{integer,9,62},default}]}}, [{cover,munge_expr,2}, {cover,munge_body,4}, {cover,munge_clauses,4}, {cover,munge,4}, {cover,transform_2,5}, {cover,transform,4}, {cover,do_compile_beam,2}, {cover,main_process_loop,1}]} in function cover:call/1 in call from cover:compile_modules/3 in call from cover:compile_module/2 in call from foo:f/0 From bgustavsson@REDACTED Fri Dec 11 23:08:24 2009 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Fri, 11 Dec 2009 23:08:24 +0100 Subject: [erlang-bugs] internal compiler faults In-Reply-To: <3299-1260541253-694178@sneakemail.com> References: <4816-1260447151-444331@sneakemail.com> <4B20F221.9040007@cs.ntua.gr> <6672d0160912101337q370f92a2o5e5bf5d186a6f824@mail.gmail.com> <3299-1260541253-694178@sneakemail.com> Message-ID: <6672d0160912111408v6abac57fh511cbe174654c6fa@mail.gmail.com> On Fri, Dec 11, 2009 at 3:20 PM, Simon Cornish wrote: > Regarding the internal consistency check, I used the beam_bool patch > and still encountered the same problem. Attached is a small example. > It will compile if no_bopt is used. It will also compile if the > boolean guard is not repeated (eg. CH2 is assigned a constant value). Fixed. Included in 'pu'. -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From zl9d97p02@REDACTED Fri Dec 11 23:42:37 2009 From: zl9d97p02@REDACTED (Simon Cornish) Date: Fri, 11 Dec 2009 23:42:37 +0100 Subject: [erlang-bugs] internal compiler faults In-Reply-To: <6672d0160912111408v6abac57fh511cbe174654c6fa@mail.gmail.com> References: <4816-1260447151-444331@sneakemail.com> <4B20F221.9040007@cs.ntua.gr> <6672d0160912101337q370f92a2o5e5bf5d186a6f824@mail.gmail.com> <3299-1260541253-694178@sneakemail.com> <6672d0160912111408v6abac57fh511cbe174654c6fa@mail.gmail.com> Message-ID: <2947-1260571358-351044@sneakemail.com> 2009/12/11 Bj?rn Gustavsson bgustavsson-at-gmail.com: > Fixed. Included in 'pu'. Cool! Thanks. From lars@REDACTED Mon Dec 14 10:16:13 2009 From: lars@REDACTED (Lars Thorsen) Date: Mon, 14 Dec 2009 10:16:13 +0100 Subject: [erlang-bugs] Building docs for R13B-03 fails In-Reply-To: References: Message-ID: <4B26025D.9020904@erix.ericsson.se> Hi Sergei, we started to build our documentation with open source tools in R13B03 so it would be possible to build the doc from the delivered sources. But it's still only built in house because we hadn't time to test it but the plan is to have it work for everyone in R13B04. Thanks for your report, we'll have a look at those fault. Regards Lars Sergei Golovan wrote: > Hi! > > I'm trying to build Erlang documentation from the sources (the goal is > to switch from prebuilt docs for Debian Erlang packages as building > them from the source is preferable). > > To do that I run > make > make TYPE=docs > (in fact, make libs doesn't recognize TYPE, so I had to replace "make > opt" by "make $(TYPE) in the top-level Makefile). > > and I've found several problems which make build fail: > > 1) For some XML files (e.g. erts/docs/src/book.xml) xsltproc reports > runtime errors about undefined variables (partnum in line 871 and 963 > of db_pdf.xsl, in lines 1075 and 1173 of db_html.xsl). Is this a bug > in the stylesheets or in xsltproc? (Both 1.1.24 from Debian stable and > 1.1.26 from Debian unstable failed.) > > 2) wx application has duplicated targets html and docs in its makefile. > > 3) wx application (and others too) require docb_gen script to generate > XML docs sources. It is missing. (I suppose that it is a simple > wrapper around docb_gen Erlang module and could be recreated, but It'd > be better if it were shipped in Erlang sources.) > > Is Erlang documentation supposed to be buildable from the source, or > it still requires some unavailable tools? > > Cheers! From sgolovan@REDACTED Mon Dec 14 11:02:12 2009 From: sgolovan@REDACTED (Sergei Golovan) Date: Mon, 14 Dec 2009 13:02:12 +0300 Subject: [erlang-bugs] Building docs for R13B-03 fails In-Reply-To: <4B26025D.9020904@erix.ericsson.se> References: <4B26025D.9020904@erix.ericsson.se> Message-ID: Hi! I did some further investigations and found that simply calling make in all doc/src directories works better then trying to run make recursively. pwd=`pwd` for i in `find . -wholename '*/doc/src'` ; do (cd $i ; make man ERL_TOP=$pwd ) done (using Erlang R12B-02-1 edoc and docbuilder, and the attached docb_gen script) generates manpages perfectly, make html and make pdf though suffer from runtime errors while running xsltproc. Running make recursively reveals a whole bunch of problems with missing and redefined 'docs' targets in makefiles. On Mon, Dec 14, 2009 at 12:16 PM, wrote: > Hi Sergei, > we started to build our documentation with open source tools in R13B03 so it > would be possible to build the doc from the delivered sources. > > But it's still only built in house because we hadn't time to test it but the plan is > to have it work for everyone in R13B04. > > Thanks for your report, we'll have a look at those fault. > > Regards Lars > > > Sergei Golovan wrote: >> Hi! >> >> I'm trying to build Erlang documentation from the sources (the goal is >> to switch from prebuilt docs for Debian Erlang packages as building >> them from the source is preferable). >> >> To do that I run >> make >> make TYPE=docs >> (in fact, make libs doesn't recognize TYPE, so I had to replace "make >> opt" by "make $(TYPE) in the top-level Makefile). >> >> and I've found several problems which make build fail: >> >> 1) For some XML files (e.g. erts/docs/src/book.xml) xsltproc reports >> runtime errors about undefined variables (partnum in line 871 and 963 >> of db_pdf.xsl, in lines 1075 and 1173 of db_html.xsl). Is this a bug >> in the stylesheets or in xsltproc? (Both 1.1.24 from Debian stable and >> 1.1.26 from Debian unstable failed.) >> >> 2) wx application has duplicated targets html and docs in its makefile. >> >> 3) wx application (and others too) require docb_gen script to generate >> XML docs sources. It is missing. (I suppose that it is a simple >> wrapper around docb_gen Erlang module and could be recreated, but It'd >> be better if it were shipped in Erlang sources.) >> >> Is Erlang documentation supposed to be buildable from the source, or >> it still requires some unavailable tools? >> >> Cheers! > > -- Sergei Golovan -------------- next part -------------- A non-text attachment was scrubbed... Name: docb_gen Type: application/octet-stream Size: 1498 bytes Desc: not available URL: From bengt.kleberg@REDACTED Mon Dec 14 11:19:10 2009 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Mon, 14 Dec 2009 11:19:10 +0100 Subject: OT: [erlang-bugs] Building docs for R13B-03 fails In-Reply-To: References: <4B26025D.9020904@erix.ericsson.se> Message-ID: <1260785950.4760.10.camel@seasc1137.dyn.rnd.as.sw.ericsson.se> Greetings, It has been well over a year since last time I mentioned this paper "Recursive Make Considered Harmful", (http://miller.emu.id.au/pmiller/books/rmch/). so I hope it is ok that I do it again. Nice little reading for those that find themselves wondering if they are the only ones that think make is somewhat lacking, at times. bengt On Mon, 2009-12-14 at 13:02 +0300, Sergei Golovan wrote: > Hi! > > I did some further investigations and found that simply calling make > in all doc/src > directories works better then trying to run make recursively. > > pwd=`pwd` > for i in `find . -wholename '*/doc/src'` ; do > (cd $i ; make man ERL_TOP=$pwd ) > done > > (using Erlang R12B-02-1 edoc and docbuilder, and the attached docb_gen script) > generates manpages perfectly, make html and make pdf though suffer from runtime > errors while running xsltproc. > > Running make recursively reveals a whole bunch of problems with > missing and redefined > 'docs' targets in makefiles. > > On Mon, Dec 14, 2009 at 12:16 PM, wrote: > > Hi Sergei, > > we started to build our documentation with open source tools in R13B03 so it > > would be possible to build the doc from the delivered sources. > > > > But it's still only built in house because we hadn't time to test it but the plan is > > to have it work for everyone in R13B04. > > > > Thanks for your report, we'll have a look at those fault. > > > > Regards Lars > > > > > > Sergei Golovan wrote: > >> Hi! > >> > >> I'm trying to build Erlang documentation from the sources (the goal is > >> to switch from prebuilt docs for Debian Erlang packages as building > >> them from the source is preferable). > >> > >> To do that I run > >> make > >> make TYPE=docs > >> (in fact, make libs doesn't recognize TYPE, so I had to replace "make > >> opt" by "make $(TYPE) in the top-level Makefile). > >> > >> and I've found several problems which make build fail: > >> > >> 1) For some XML files (e.g. erts/docs/src/book.xml) xsltproc reports > >> runtime errors about undefined variables (partnum in line 871 and 963 > >> of db_pdf.xsl, in lines 1075 and 1173 of db_html.xsl). Is this a bug > >> in the stylesheets or in xsltproc? (Both 1.1.24 from Debian stable and > >> 1.1.26 from Debian unstable failed.) > >> > >> 2) wx application has duplicated targets html and docs in its makefile. > >> > >> 3) wx application (and others too) require docb_gen script to generate > >> XML docs sources. It is missing. (I suppose that it is a simple > >> wrapper around docb_gen Erlang module and could be recreated, but It'd > >> be better if it were shipped in Erlang sources.) > >> > >> Is Erlang documentation supposed to be buildable from the source, or > >> it still requires some unavailable tools? > >> > >> Cheers! > > > > > > > > ________________________________________________________________ > erlang-bugs mailing list. See http://www.erlang.org/faq.html > erlang-bugs (at) erlang.org From leap@REDACTED Mon Dec 14 11:47:15 2009 From: leap@REDACTED (Michael Turner) Date: Mon, 14 Dec 2009 10:47:15 +0000 Subject: Recursive Make Considered Harmful In-Reply-To: <1260785950.4760.10.camel@seasc1137.dyn.rnd.as.sw.ericsson.se> Message-ID: http://miller.emu.id.au/pmiller/books/rmch/ Thanks for this. I wasn't on the list when you first mentioned this paper. I vaguely remembered just such a paper while trying to build an Erlang release a few months ago. It struck me as a breath of fresh air when I first read it over a decade ago. It's not so much that "make" is lacking, I think. Mainly it's that the obvious approach (recursion) for building stuff out of a hierarchical directory structure is not necessarily the best way if you're using make. Having one big makefile seems, of course, horribly inelegant. But when I've tried that approach, it always reminds me of things I'd forgotten while using big, lumbering, recursive build systems. Like, make is really fast. Compilers are pretty fast, too. And having everything in one place can be nice. -michael turner On 12/14/2009, "Bengt Kleberg" wrote: >Greetings, > >It has been well over a year since last time I mentioned this paper >"Recursive Make Considered Harmful", >(http://miller.emu.id.au/pmiller/books/rmch/). so I hope it is ok that I >do it again. > >Nice little reading for those that find themselves wondering if they are >the only ones that think make is somewhat lacking, at times. > > >bengt > >On Mon, 2009-12-14 at 13:02 +0300, Sergei Golovan wrote: >> Hi! >> >> I did some further investigations and found that simply calling make >> in all doc/src >> directories works better then trying to run make recursively. >> >> pwd=`pwd` >> for i in `find . -wholename '*/doc/src'` ; do >> (cd $i ; make man ERL_TOP=$pwd ) >> done >> >> (using Erlang R12B-02-1 edoc and docbuilder, and the attached docb_gen script) >> generates manpages perfectly, make html and make pdf though suffer from runtime >> errors while running xsltproc. >> >> Running make recursively reveals a whole bunch of problems with >> missing and redefined >> 'docs' targets in makefiles. >> >> On Mon, Dec 14, 2009 at 12:16 PM, wrote: >> > Hi Sergei, >> > we started to build our documentation with open source tools in R13B03 so it >> > would be possible to build the doc from the delivered sources. >> > >> > But it's still only built in house because we hadn't time to test it but the plan is >> > to have it work for everyone in R13B04. >> > >> > Thanks for your report, we'll have a look at those fault. >> > >> > Regards Lars >> > >> > >> > Sergei Golovan wrote: >> >> Hi! >> >> >> >> I'm trying to build Erlang documentation from the sources (the goal is >> >> to switch from prebuilt docs for Debian Erlang packages as building >> >> them from the source is preferable). >> >> >> >> To do that I run >> >> make >> >> make TYPE=docs >> >> (in fact, make libs doesn't recognize TYPE, so I had to replace "make >> >> opt" by "make $(TYPE) in the top-level Makefile). >> >> >> >> and I've found several problems which make build fail: >> >> >> >> 1) For some XML files (e.g. erts/docs/src/book.xml) xsltproc reports >> >> runtime errors about undefined variables (partnum in line 871 and 963 >> >> of db_pdf.xsl, in lines 1075 and 1173 of db_html.xsl). Is this a bug >> >> in the stylesheets or in xsltproc? (Both 1.1.24 from Debian stable and >> >> 1.1.26 from Debian unstable failed.) >> >> >> >> 2) wx application has duplicated targets html and docs in its makefile. >> >> >> >> 3) wx application (and others too) require docb_gen script to generate >> >> XML docs sources. It is missing. (I suppose that it is a simple >> >> wrapper around docb_gen Erlang module and could be recreated, but It'd >> >> be better if it were shipped in Erlang sources.) >> >> >> >> Is Erlang documentation supposed to be buildable from the source, or >> >> it still requires some unavailable tools? >> >> >> >> Cheers! >> > >> > >> >> >> >> ________________________________________________________________ >> erlang-bugs mailing list. See http://www.erlang.org/faq.html >> erlang-bugs (at) erlang.org > > >________________________________________________________________ >erlang-bugs mailing list. See http://www.erlang.org/faq.html >erlang-bugs (at) erlang.org > > From bengt.kleberg@REDACTED Mon Dec 14 12:28:47 2009 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Mon, 14 Dec 2009 12:28:47 +0100 Subject: Recursive Make Considered Harmful In-Reply-To: References: Message-ID: <1260790128.4760.17.camel@seasc1137.dyn.rnd.as.sw.ericsson.se> The proposed solution, which you aptly name "horribly inelegant", always suggests to me that make should be replaced. At least for new things. bengt On Mon, 2009-12-14 at 10:47 +0000, Michael Turner wrote: > http://miller.emu.id.au/pmiller/books/rmch/ > > Thanks for this. I wasn't on the list when you first mentioned this > paper. I vaguely remembered just such a paper while trying to build an > Erlang release a few months ago. It struck me as a breath of fresh air > when I first read it over a decade ago. > > It's not so much that "make" is lacking, I think. Mainly it's that > the obvious approach (recursion) for building stuff out of a > hierarchical directory structure is not necessarily the best way if > you're using make. > > Having one big makefile seems, of course, horribly inelegant. But when > I've tried that approach, it always reminds me of things I'd forgotten > while using big, lumbering, recursive build systems. Like, make is > really fast. Compilers are pretty fast, too. And having everything in > one place can be nice. > > -michael turner > > On 12/14/2009, "Bengt Kleberg" wrote: > > >Greetings, > > > >It has been well over a year since last time I mentioned this paper > >"Recursive Make Considered Harmful", > >(http://miller.emu.id.au/pmiller/books/rmch/). so I hope it is ok that I > >do it again. > > > >Nice little reading for those that find themselves wondering if they are > >the only ones that think make is somewhat lacking, at times. > > > > > >bengt > > > >On Mon, 2009-12-14 at 13:02 +0300, Sergei Golovan wrote: > >> Hi! > >> > >> I did some further investigations and found that simply calling make > >> in all doc/src > >> directories works better then trying to run make recursively. > >> > >> pwd=`pwd` > >> for i in `find . -wholename '*/doc/src'` ; do > >> (cd $i ; make man ERL_TOP=$pwd ) > >> done > >> > >> (using Erlang R12B-02-1 edoc and docbuilder, and the attached docb_gen script) > >> generates manpages perfectly, make html and make pdf though suffer from runtime > >> errors while running xsltproc. > >> > >> Running make recursively reveals a whole bunch of problems with > >> missing and redefined > >> 'docs' targets in makefiles. > >> > >> On Mon, Dec 14, 2009 at 12:16 PM, wrote: > >> > Hi Sergei, > >> > we started to build our documentation with open source tools in R13B03 so it > >> > would be possible to build the doc from the delivered sources. > >> > > >> > But it's still only built in house because we hadn't time to test it but the plan is > >> > to have it work for everyone in R13B04. > >> > > >> > Thanks for your report, we'll have a look at those fault. > >> > > >> > Regards Lars > >> > > >> > > >> > Sergei Golovan wrote: > >> >> Hi! > >> >> > >> >> I'm trying to build Erlang documentation from the sources (the goal is > >> >> to switch from prebuilt docs for Debian Erlang packages as building > >> >> them from the source is preferable). > >> >> > >> >> To do that I run > >> >> make > >> >> make TYPE=docs > >> >> (in fact, make libs doesn't recognize TYPE, so I had to replace "make > >> >> opt" by "make $(TYPE) in the top-level Makefile). > >> >> > >> >> and I've found several problems which make build fail: > >> >> > >> >> 1) For some XML files (e.g. erts/docs/src/book.xml) xsltproc reports > >> >> runtime errors about undefined variables (partnum in line 871 and 963 > >> >> of db_pdf.xsl, in lines 1075 and 1173 of db_html.xsl). Is this a bug > >> >> in the stylesheets or in xsltproc? (Both 1.1.24 from Debian stable and > >> >> 1.1.26 from Debian unstable failed.) > >> >> > >> >> 2) wx application has duplicated targets html and docs in its makefile. > >> >> > >> >> 3) wx application (and others too) require docb_gen script to generate > >> >> XML docs sources. It is missing. (I suppose that it is a simple > >> >> wrapper around docb_gen Erlang module and could be recreated, but It'd > >> >> be better if it were shipped in Erlang sources.) > >> >> > >> >> Is Erlang documentation supposed to be buildable from the source, or > >> >> it still requires some unavailable tools? > >> >> > >> >> Cheers! > >> > > >> > > >> > >> > >> > >> ________________________________________________________________ > >> erlang-bugs mailing list. See http://www.erlang.org/faq.html > >> erlang-bugs (at) erlang.org > > > > > >________________________________________________________________ > >erlang-bugs mailing list. See http://www.erlang.org/faq.html > >erlang-bugs (at) erlang.org > > > > From hans.bolinder@REDACTED Mon Dec 14 15:20:29 2009 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Mon, 14 Dec 2009 15:20:29 +0100 Subject: [erlang-bugs] Cover blows up on parsing binary comprehension In-Reply-To: <20091211161119.GA598@wellquite.org> References: <20091211161119.GA598@wellquite.org> Message-ID: <19238.18861.393655.591898@ornendil.du.uab.ericsson.se> [Matthew Sackman:] > g(SeqIds) -> << <<3:2, SeqId:62>> || SeqId <- SeqIds >>. Thanks! There is a patch on GitHub, see http://github.com/erlang/otp/commit/420b28bb007946307eeda5d4e2bf200fe0ee25ba Best regards, Hans Bolinder, Erlang/OTP team, Ericsson From toby@REDACTED Mon Dec 14 19:07:18 2009 From: toby@REDACTED (Toby Thain) Date: Mon, 14 Dec 2009 13:07:18 -0500 Subject: [erlang-bugs] Re: Recursive Make Considered Harmful In-Reply-To: References: Message-ID: <9B3BA93B-FBE4-45FB-97B3-676BED0B7565@telegraphics.com.au> On 14-Dec-09, at 5:47 AM, Michael Turner wrote: > > http://miller.emu.id.au/pmiller/books/rmch/ > > Thanks for this. I wasn't on the list when you first mentioned this > paper. I vaguely remembered just such a paper while trying to build an > Erlang release a few months ago. It struck me as a breath of fresh > air > when I first read it over a decade ago. > > It's not so much that "make" is lacking, I think. Right, the problem isn't with 'make' per se, which the paper serves to prove. --Toby > Mainly it's that > the obvious approach (recursion) for building stuff out of a > hierarchical directory structure is not necessarily the best way if > you're using make. > > Having one big makefile seems, of course, horribly inelegant. But > when > I've tried that approach, it always reminds me of things I'd forgotten > while using big, lumbering, recursive build systems. Like, make is > really fast. Compilers are pretty fast, too. And having > everything in > one place can be nice. > > -michael turner > > On 12/14/2009, "Bengt Kleberg" wrote: > >> Greetings, >> >> It has been well over a year since last time I mentioned this paper >> "Recursive Make Considered Harmful", >> (http://miller.emu.id.au/pmiller/books/rmch/). so I hope it is ok >> that I >> do it again. >> >> Nice little reading for those that find themselves wondering if >> they are >> the only ones that think make is somewhat lacking, at times. >> >> >> bengt >> >> On Mon, 2009-12-14 at 13:02 +0300, Sergei Golovan wrote: >>> Hi! >>> >>> I did some further investigations and found that simply calling make >>> in all doc/src >>> directories works better then trying to run make recursively. >>> >>> pwd=`pwd` >>> for i in `find . -wholename '*/doc/src'` ; do >>> (cd $i ; make man ERL_TOP=$pwd ) >>> done >>> >>> (using Erlang R12B-02-1 edoc and docbuilder, and the attached >>> docb_gen script) >>> generates manpages perfectly, make html and make pdf though >>> suffer from runtime >>> errors while running xsltproc. >>> >>> Running make recursively reveals a whole bunch of problems with >>> missing and redefined >>> 'docs' targets in makefiles. >>> >>> On Mon, Dec 14, 2009 at 12:16 PM, wrote: >>>> Hi Sergei, >>>> we started to build our documentation with open source tools in >>>> R13B03 so it >>>> would be possible to build the doc from the delivered sources. >>>> >>>> But it's still only built in house because we hadn't time to >>>> test it but the plan is >>>> to have it work for everyone in R13B04. >>>> >>>> Thanks for your report, we'll have a look at those fault. >>>> >>>> Regards Lars >>>> >>>> >>>> Sergei Golovan wrote: >>>>> Hi! >>>>> >>>>> I'm trying to build Erlang documentation from the sources (the >>>>> goal is >>>>> to switch from prebuilt docs for Debian Erlang packages as >>>>> building >>>>> them from the source is preferable). >>>>> >>>>> To do that I run >>>>> make >>>>> make TYPE=docs >>>>> (in fact, make libs doesn't recognize TYPE, so I had to replace >>>>> "make >>>>> opt" by "make $(TYPE) in the top-level Makefile). >>>>> >>>>> and I've found several problems which make build fail: >>>>> >>>>> 1) For some XML files (e.g. erts/docs/src/book.xml) xsltproc >>>>> reports >>>>> runtime errors about undefined variables (partnum in line 871 >>>>> and 963 >>>>> of db_pdf.xsl, in lines 1075 and 1173 of db_html.xsl). Is this >>>>> a bug >>>>> in the stylesheets or in xsltproc? (Both 1.1.24 from Debian >>>>> stable and >>>>> 1.1.26 from Debian unstable failed.) >>>>> >>>>> 2) wx application has duplicated targets html and docs in its >>>>> makefile. >>>>> >>>>> 3) wx application (and others too) require docb_gen script to >>>>> generate >>>>> XML docs sources. It is missing. (I suppose that it is a simple >>>>> wrapper around docb_gen Erlang module and could be recreated, >>>>> but It'd >>>>> be better if it were shipped in Erlang sources.) >>>>> >>>>> Is Erlang documentation supposed to be buildable from the >>>>> source, or >>>>> it still requires some unavailable tools? >>>>> >>>>> Cheers! >>>> >>>> >>> >>> >>> >>> ________________________________________________________________ >>> erlang-bugs mailing list. See http://www.erlang.org/faq.html >>> erlang-bugs (at) erlang.org >> >> >> ________________________________________________________________ >> erlang-bugs mailing list. See http://www.erlang.org/faq.html >> erlang-bugs (at) erlang.org >> >> > > ________________________________________________________________ > erlang-bugs mailing list. See http://www.erlang.org/faq.html > erlang-bugs (at) erlang.org > From bengt.kleberg@REDACTED Tue Dec 15 09:55:16 2009 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Tue, 15 Dec 2009 09:55:16 +0100 Subject: OT: [erlang-bugs] Re: Recursive Make Considered Harmful In-Reply-To: <9B3BA93B-FBE4-45FB-97B3-676BED0B7565@telegraphics.com.au> References: <9B3BA93B-FBE4-45FB-97B3-676BED0B7565@telegraphics.com.au> Message-ID: <1260867316.5153.9.camel@seasc1137.dyn.rnd.as.sw.ericsson.se> Greetings, Perhaps I am mistaken, but I think the solution presented in the paper, while being better than recursive make, is cumbersome and fragile. So I would say that make is lacking, once the project leaves a single directory. bengt On Mon, 2009-12-14 at 13:07 -0500, Toby Thain wrote: > On 14-Dec-09, at 5:47 AM, Michael Turner wrote: > > > > > http://miller.emu.id.au/pmiller/books/rmch/ > > > > Thanks for this. I wasn't on the list when you first mentioned this > > paper. I vaguely remembered just such a paper while trying to build an > > Erlang release a few months ago. It struck me as a breath of fresh > > air > > when I first read it over a decade ago. > > > > It's not so much that "make" is lacking, I think. > > Right, the problem isn't with 'make' per se, which the paper serves > to prove. > > --Toby > > > Mainly it's that > > the obvious approach (recursion) for building stuff out of a > > hierarchical directory structure is not necessarily the best way if > > you're using make. > > > > Having one big makefile seems, of course, horribly inelegant. But > > when > > I've tried that approach, it always reminds me of things I'd forgotten > > while using big, lumbering, recursive build systems. Like, make is > > really fast. Compilers are pretty fast, too. And having > > everything in > > one place can be nice. > > > > -michael turner > > > > On 12/14/2009, "Bengt Kleberg" wrote: > > > >> Greetings, > >> > >> It has been well over a year since last time I mentioned this paper > >> "Recursive Make Considered Harmful", > >> (http://miller.emu.id.au/pmiller/books/rmch/). so I hope it is ok > >> that I > >> do it again. > >> > >> Nice little reading for those that find themselves wondering if > >> they are > >> the only ones that think make is somewhat lacking, at times. > >> > >> > >> bengt > >> > >> On Mon, 2009-12-14 at 13:02 +0300, Sergei Golovan wrote: > >>> Hi! > >>> > >>> I did some further investigations and found that simply calling make > >>> in all doc/src > >>> directories works better then trying to run make recursively. > >>> > >>> pwd=`pwd` > >>> for i in `find . -wholename '*/doc/src'` ; do > >>> (cd $i ; make man ERL_TOP=$pwd ) > >>> done > >>> > >>> (using Erlang R12B-02-1 edoc and docbuilder, and the attached > >>> docb_gen script) > >>> generates manpages perfectly, make html and make pdf though > >>> suffer from runtime > >>> errors while running xsltproc. > >>> > >>> Running make recursively reveals a whole bunch of problems with > >>> missing and redefined > >>> 'docs' targets in makefiles. > >>> > >>> On Mon, Dec 14, 2009 at 12:16 PM, wrote: > >>>> Hi Sergei, > >>>> we started to build our documentation with open source tools in > >>>> R13B03 so it > >>>> would be possible to build the doc from the delivered sources. > >>>> > >>>> But it's still only built in house because we hadn't time to > >>>> test it but the plan is > >>>> to have it work for everyone in R13B04. > >>>> > >>>> Thanks for your report, we'll have a look at those fault. > >>>> > >>>> Regards Lars > >>>> > >>>> > >>>> Sergei Golovan wrote: > >>>>> Hi! > >>>>> > >>>>> I'm trying to build Erlang documentation from the sources (the > >>>>> goal is > >>>>> to switch from prebuilt docs for Debian Erlang packages as > >>>>> building > >>>>> them from the source is preferable). > >>>>> > >>>>> To do that I run > >>>>> make > >>>>> make TYPE=docs > >>>>> (in fact, make libs doesn't recognize TYPE, so I had to replace > >>>>> "make > >>>>> opt" by "make $(TYPE) in the top-level Makefile). > >>>>> > >>>>> and I've found several problems which make build fail: > >>>>> > >>>>> 1) For some XML files (e.g. erts/docs/src/book.xml) xsltproc > >>>>> reports > >>>>> runtime errors about undefined variables (partnum in line 871 > >>>>> and 963 > >>>>> of db_pdf.xsl, in lines 1075 and 1173 of db_html.xsl). Is this > >>>>> a bug > >>>>> in the stylesheets or in xsltproc? (Both 1.1.24 from Debian > >>>>> stable and > >>>>> 1.1.26 from Debian unstable failed.) > >>>>> > >>>>> 2) wx application has duplicated targets html and docs in its > >>>>> makefile. > >>>>> > >>>>> 3) wx application (and others too) require docb_gen script to > >>>>> generate > >>>>> XML docs sources. It is missing. (I suppose that it is a simple > >>>>> wrapper around docb_gen Erlang module and could be recreated, > >>>>> but It'd > >>>>> be better if it were shipped in Erlang sources.) > >>>>> > >>>>> Is Erlang documentation supposed to be buildable from the > >>>>> source, or > >>>>> it still requires some unavailable tools? > >>>>> > >>>>> Cheers! > >>>> > >>>> > >>> > >>> > >>> > >>> ________________________________________________________________ > >>> erlang-bugs mailing list. See http://www.erlang.org/faq.html > >>> erlang-bugs (at) erlang.org > >> > >> > >> ________________________________________________________________ > >> erlang-bugs mailing list. See http://www.erlang.org/faq.html > >> erlang-bugs (at) erlang.org > >> > >> > > > > ________________________________________________________________ > > erlang-bugs mailing list. See http://www.erlang.org/faq.html > > erlang-bugs (at) erlang.org > > > From leap@REDACTED Tue Dec 15 11:14:51 2009 From: leap@REDACTED (Michael Turner) Date: Tue, 15 Dec 2009 10:14:51 +0000 Subject: Recursive Make Considered Harmful (OT?) In-Reply-To: <1260867316.5153.9.camel@seasc1137.dyn.rnd.as.sw.ericsson.se> Message-ID: <1S9ZyBvp.1260872091.8891750.leap@gol.com> On 12/15/2009, "Bengt Kleberg" wrote: >Perhaps I am mistaken, but I think the solution presented in the paper, >while being better than recursive make, is cumbersome and fragile. So I >would say that make is lacking, once the project leaves a single >directory. What do you mean by "leaves a single directory?" The only interpretation I can think of is: "has source files in more than one directory." Whatever the demerits of the approach suggested, it's clearly not limited to single-directory builds. It's a way to have one big makefile (composed of some fragments of makefiles in subdirectories) for something you're building in several directories. >From the beginning of the Implementation Notes: "The most basic problem to overcome when implementing single-session make is to avoid flattening your directory structure, while joining the dependency information present in each subdirectory in a single tree." So what did you mean by "leaves a single directory"? -michael turner >On Mon, 2009-12-14 at 13:07 -0500, Toby Thain wrote: >> On 14-Dec-09, at 5:47 AM, Michael Turner wrote: >> >> > >> > http://miller.emu.id.au/pmiller/books/rmch/ >> > >> > Thanks for this. I wasn't on the list when you first mentioned this >> > paper. I vaguely remembered just such a paper while trying to build an >> > Erlang release a few months ago. It struck me as a breath of fresh >> > air >> > when I first read it over a decade ago. >> > >> > It's not so much that "make" is lacking, I think. >> >> Right, the problem isn't with 'make' per se, which the paper serves >> to prove. >> >> --Toby >> >> > Mainly it's that >> > the obvious approach (recursion) for building stuff out of a >> > hierarchical directory structure is not necessarily the best way if >> > you're using make. >> > >> > Having one big makefile seems, of course, horribly inelegant. But >> > when >> > I've tried that approach, it always reminds me of things I'd forgotten >> > while using big, lumbering, recursive build systems. Like, make is >> > really fast. Compilers are pretty fast, too. And having >> > everything in >> > one place can be nice. >> > >> > -michael turner >> > >> > On 12/14/2009, "Bengt Kleberg" wrote: >> > >> >> Greetings, >> >> >> >> It has been well over a year since last time I mentioned this paper >> >> "Recursive Make Considered Harmful", >> >> (http://miller.emu.id.au/pmiller/books/rmch/). so I hope it is ok >> >> that I >> >> do it again. >> >> >> >> Nice little reading for those that find themselves wondering if >> >> they are >> >> the only ones that think make is somewhat lacking, at times. >> >> >> >> >> >> bengt >> >> >> >> On Mon, 2009-12-14 at 13:02 +0300, Sergei Golovan wrote: >> >>> Hi! >> >>> >> >>> I did some further investigations and found that simply calling make >> >>> in all doc/src >> >>> directories works better then trying to run make recursively. >> >>> >> >>> pwd=`pwd` >> >>> for i in `find . -wholename '*/doc/src'` ; do >> >>> (cd $i ; make man ERL_TOP=$pwd ) >> >>> done >> >>> >> >>> (using Erlang R12B-02-1 edoc and docbuilder, and the attached >> >>> docb_gen script) >> >>> generates manpages perfectly, make html and make pdf though >> >>> suffer from runtime >> >>> errors while running xsltproc. >> >>> >> >>> Running make recursively reveals a whole bunch of problems with >> >>> missing and redefined >> >>> 'docs' targets in makefiles. >> >>> >> >>> On Mon, Dec 14, 2009 at 12:16 PM, wrote: >> >>>> Hi Sergei, >> >>>> we started to build our documentation with open source tools in >> >>>> R13B03 so it >> >>>> would be possible to build the doc from the delivered sources. >> >>>> >> >>>> But it's still only built in house because we hadn't time to >> >>>> test it but the plan is >> >>>> to have it work for everyone in R13B04. >> >>>> >> >>>> Thanks for your report, we'll have a look at those fault. >> >>>> >> >>>> Regards Lars >> >>>> >> >>>> >> >>>> Sergei Golovan wrote: >> >>>>> Hi! >> >>>>> >> >>>>> I'm trying to build Erlang documentation from the sources (the >> >>>>> goal is >> >>>>> to switch from prebuilt docs for Debian Erlang packages as >> >>>>> building >> >>>>> them from the source is preferable). >> >>>>> >> >>>>> To do that I run >> >>>>> make >> >>>>> make TYPE=docs >> >>>>> (in fact, make libs doesn't recognize TYPE, so I had to replace >> >>>>> "make >> >>>>> opt" by "make $(TYPE) in the top-level Makefile). >> >>>>> >> >>>>> and I've found several problems which make build fail: >> >>>>> >> >>>>> 1) For some XML files (e.g. erts/docs/src/book.xml) xsltproc >> >>>>> reports >> >>>>> runtime errors about undefined variables (partnum in line 871 >> >>>>> and 963 >> >>>>> of db_pdf.xsl, in lines 1075 and 1173 of db_html.xsl). Is this >> >>>>> a bug >> >>>>> in the stylesheets or in xsltproc? (Both 1.1.24 from Debian >> >>>>> stable and >> >>>>> 1.1.26 from Debian unstable failed.) >> >>>>> >> >>>>> 2) wx application has duplicated targets html and docs in its >> >>>>> makefile. >> >>>>> >> >>>>> 3) wx application (and others too) require docb_gen script to >> >>>>> generate >> >>>>> XML docs sources. It is missing. (I suppose that it is a simple >> >>>>> wrapper around docb_gen Erlang module and could be recreated, >> >>>>> but It'd >> >>>>> be better if it were shipped in Erlang sources.) >> >>>>> >> >>>>> Is Erlang documentation supposed to be buildable from the >> >>>>> source, or >> >>>>> it still requires some unavailable tools? >> >>>>> >> >>>>> Cheers! >> >>>> >> >>>> >> >>> >> >>> >> >>> >> >>> ________________________________________________________________ >> >>> erlang-bugs mailing list. See http://www.erlang.org/faq.html >> >>> erlang-bugs (at) erlang.org >> >> >> >> >> >> ________________________________________________________________ >> >> erlang-bugs mailing list. See http://www.erlang.org/faq.html >> >> erlang-bugs (at) erlang.org >> >> >> >> >> > >> > ________________________________________________________________ >> > erlang-bugs mailing list. See http://www.erlang.org/faq.html >> > erlang-bugs (at) erlang.org >> > >> > > >________________________________________________________________ >erlang-bugs mailing list. See http://www.erlang.org/faq.html >erlang-bugs (at) erlang.org > > From brunorijsman@REDACTED Tue Dec 15 13:36:20 2009 From: brunorijsman@REDACTED (Bruno Rijsman) Date: Tue, 15 Dec 2009 07:36:20 -0500 Subject: [R13B02] Error message and duplicate menu item after debugger:start() on Mac OS X 10.6.1 Message-ID: The following bug was observed running Erlang R13B02 on Mac OS X 10.6.1 Start an erl shell: erl Start the debugger: debugger:start(). The debugger window opens. At this point in time the menu items for the debugger window are: beam.smp, File, Edit, Module, Process, Break, Options, Windows, Help, Window. Click on the Help menu item. A drop down menu with the options Search and Debugger appears. In the Erl shell the following error message appears: 2009-12-15 07:18:10.894 beam.smp[2675:3903] Calling -[NSMenuItemViewer _getMenuItemViewerHIViewClassRegisteringIfNecessary] off the main thread. This is not supported and will likely crash. The menu changes and now includes the following items: beam.smp, File, Edit, Module, Process, Break, Options, Windows, Help, Window, Help. Note that the Help item is present twice. The first Help item has a drop down menu with a single item Debugger. The second Help item has a drop down menu with a single item Search. From bengt.kleberg@REDACTED Wed Dec 16 14:42:39 2009 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Wed, 16 Dec 2009 14:42:39 +0100 Subject: OT: Recursive Make Considered Harmful (OT?) In-Reply-To: <1S9ZyBvp.1260872091.8891750.leap@gol.com> References: <1S9ZyBvp.1260872091.8891750.leap@gol.com> Message-ID: <1260970959.4762.46.camel@seasc1137.dyn.rnd.as.sw.ericsson.se> Greetings, Perhaps you would consider moving this off the list? I do not think my meager experience with non-recursive make warrants much more than the link to the paper. However, you are spot on. I did mean "has source files in more than one directory." You are also correct in stating that the paper describes how to have one large makefile for several directories. My comments where intended to convey the following basic statements: - Recursive make can be viewed as sub-optimal due to the reason put forth in the paper. - Non-recursive make I found to be sub-optimal due to it being cumbersome and fragile. And my thus conclusion: - make is lacking, once the project has source files in more than one directory. bengt > On Tue, 2009-12-15 at 10:14 +0000, Michael Turner wrote: > > On 12/15/2009, "Bengt Kleberg" wrote: > > >Perhaps I am mistaken, but I think the solution presented in the paper, > >while being better than recursive make, is cumbersome and fragile. So I > >would say that make is lacking, once the project leaves a single > >directory. > > What do you mean by "leaves a single directory?" The only > interpretation I can think of is: "has source files in more than one > directory." Whatever the demerits of the approach suggested, it's > clearly not limited to single-directory builds. It's a way to have one > big makefile (composed of some fragments of makefiles in subdirectories) > for something you're building in several directories. > > From the beginning of the Implementation Notes: > > "The most basic problem to overcome when implementing single-session > make is to avoid flattening your directory structure, while joining the > dependency information present in each subdirectory in a single tree." > > So what did you mean by "leaves a single directory"? > > -michael turner > > >On Mon, 2009-12-14 at 13:07 -0500, Toby Thain wrote: > >> On 14-Dec-09, at 5:47 AM, Michael Turner wrote: > >> > >> > > >> > http://miller.emu.id.au/pmiller/books/rmch/ > >> > > >> > Thanks for this. I wasn't on the list when you first mentioned this > >> > paper. I vaguely remembered just such a paper while trying to build an > >> > Erlang release a few months ago. It struck me as a breath of fresh > >> > air > >> > when I first read it over a decade ago. > >> > > >> > It's not so much that "make" is lacking, I think. > >> > >> Right, the problem isn't with 'make' per se, which the paper serves > >> to prove. > >> > >> --Toby > >> > >> > Mainly it's that > >> > the obvious approach (recursion) for building stuff out of a > >> > hierarchical directory structure is not necessarily the best way if > >> > you're using make. > >> > > >> > Having one big makefile seems, of course, horribly inelegant. But > >> > when > >> > I've tried that approach, it always reminds me of things I'd forgotten > >> > while using big, lumbering, recursive build systems. Like, make is > >> > really fast. Compilers are pretty fast, too. And having > >> > everything in > >> > one place can be nice. > >> > > >> > -michael turner > >> > > >> > On 12/14/2009, "Bengt Kleberg" wrote: > >> > > >> >> Greetings, > >> >> > >> >> It has been well over a year since last time I mentioned this paper > >> >> "Recursive Make Considered Harmful", > >> >> (http://miller.emu.id.au/pmiller/books/rmch/). so I hope it is ok > >> >> that I > >> >> do it again. > >> >> > >> >> Nice little reading for those that find themselves wondering if > >> >> they are > >> >> the only ones that think make is somewhat lacking, at times. > >> >> > >> >> > >> >> bengt > >> >> > >> >> On Mon, 2009-12-14 at 13:02 +0300, Sergei Golovan wrote: > >> >>> Hi! > >> >>> > >> >>> I did some further investigations and found that simply calling make > >> >>> in all doc/src > >> >>> directories works better then trying to run make recursively. > >> >>> > >> >>> pwd=`pwd` > >> >>> for i in `find . -wholename '*/doc/src'` ; do > >> >>> (cd $i ; make man ERL_TOP=$pwd ) > >> >>> done > >> >>> > >> >>> (using Erlang R12B-02-1 edoc and docbuilder, and the attached > >> >>> docb_gen script) > >> >>> generates manpages perfectly, make html and make pdf though > >> >>> suffer from runtime > >> >>> errors while running xsltproc. > >> >>> > >> >>> Running make recursively reveals a whole bunch of problems with > >> >>> missing and redefined > >> >>> 'docs' targets in makefiles. > >> >>> > >> >>> On Mon, Dec 14, 2009 at 12:16 PM, wrote: > >> >>>> Hi Sergei, > >> >>>> we started to build our documentation with open source tools in > >> >>>> R13B03 so it > >> >>>> would be possible to build the doc from the delivered sources. > >> >>>> > >> >>>> But it's still only built in house because we hadn't time to > >> >>>> test it but the plan is > >> >>>> to have it work for everyone in R13B04. > >> >>>> > >> >>>> Thanks for your report, we'll have a look at those fault. > >> >>>> > >> >>>> Regards Lars > >> >>>> > >> >>>> > >> >>>> Sergei Golovan wrote: > >> >>>>> Hi! > >> >>>>> > >> >>>>> I'm trying to build Erlang documentation from the sources (the > >> >>>>> goal is > >> >>>>> to switch from prebuilt docs for Debian Erlang packages as > >> >>>>> building > >> >>>>> them from the source is preferable). > >> >>>>> > >> >>>>> To do that I run > >> >>>>> make > >> >>>>> make TYPE=docs > >> >>>>> (in fact, make libs doesn't recognize TYPE, so I had to replace > >> >>>>> "make > >> >>>>> opt" by "make $(TYPE) in the top-level Makefile). > >> >>>>> > >> >>>>> and I've found several problems which make build fail: > >> >>>>> > >> >>>>> 1) For some XML files (e.g. erts/docs/src/book.xml) xsltproc > >> >>>>> reports > >> >>>>> runtime errors about undefined variables (partnum in line 871 > >> >>>>> and 963 > >> >>>>> of db_pdf.xsl, in lines 1075 and 1173 of db_html.xsl). Is this > >> >>>>> a bug > >> >>>>> in the stylesheets or in xsltproc? (Both 1.1.24 from Debian > >> >>>>> stable and > >> >>>>> 1.1.26 from Debian unstable failed.) > >> >>>>> > >> >>>>> 2) wx application has duplicated targets html and docs in its > >> >>>>> makefile. > >> >>>>> > >> >>>>> 3) wx application (and others too) require docb_gen script to > >> >>>>> generate > >> >>>>> XML docs sources. It is missing. (I suppose that it is a simple > >> >>>>> wrapper around docb_gen Erlang module and could be recreated, > >> >>>>> but It'd > >> >>>>> be better if it were shipped in Erlang sources.) > >> >>>>> > >> >>>>> Is Erlang documentation supposed to be buildable from the > >> >>>>> source, or > >> >>>>> it still requires some unavailable tools? > >> >>>>> > >> >>>>> Cheers! > >> >>>> > >> >>>> > >> >>> > >> >>> > >> >>> > >> >>> ________________________________________________________________ > >> >>> erlang-bugs mailing list. See http://www.erlang.org/faq.html > >> >>> erlang-bugs (at) erlang.org > >> >> > >> >> > >> >> ________________________________________________________________ > >> >> erlang-bugs mailing list. See http://www.erlang.org/faq.html > >> >> erlang-bugs (at) erlang.org > >> >> > >> >> > >> > > >> > ________________________________________________________________ > >> > erlang-bugs mailing list. See http://www.erlang.org/faq.html > >> > erlang-bugs (at) erlang.org > >> > > >> > > > > > >________________________________________________________________ > >erlang-bugs mailing list. See http://www.erlang.org/faq.html > >erlang-bugs (at) erlang.org > > > > From anders.nygren@REDACTED Wed Dec 16 16:21:59 2009 From: anders.nygren@REDACTED (Anders Nygren) Date: Wed, 16 Dec 2009 09:21:59 -0600 Subject: OT: [erlang-bugs] Building docs for R13B-03 fails In-Reply-To: <1260785950.4760.10.camel@seasc1137.dyn.rnd.as.sw.ericsson.se> References: <4B26025D.9020904@erix.ericsson.se> <1260785950.4760.10.camel@seasc1137.dyn.rnd.as.sw.ericsson.se> Message-ID: On Mon, Dec 14, 2009 at 4:19 AM, Bengt Kleberg wrote: > Greetings, > > It has been well over a year since last time I mentioned this paper > "Recursive Make Considered Harmful", > (http://miller.emu.id.au/pmiller/books/rmch/). so I hope it is ok that I > do it again. > > Nice little reading for those that find themselves wondering if they are > the only ones that think make is somewhat lacking, at times. For anyone interested there is http://code.google.com/p/erlang-t-build/ Which provides non-recursive make for erlang projects /Anders > > > bengt > > On Mon, 2009-12-14 at 13:02 +0300, Sergei Golovan wrote: >> Hi! >> >> I did some further investigations and found that simply calling make >> in all doc/src >> directories works better then trying to run make recursively. >> >> pwd=`pwd` >> for i in `find . -wholename '*/doc/src'` ; do >> ? ? (cd $i ; make man ERL_TOP=$pwd ) >> done >> >> (using Erlang R12B-02-1 edoc and docbuilder, and the attached docb_gen script) >> generates manpages perfectly, make html and make pdf though suffer from runtime >> errors while running xsltproc. >> >> Running make recursively reveals a whole bunch of problems with >> missing and redefined >> 'docs' targets in makefiles. >> >> On Mon, Dec 14, 2009 at 12:16 PM, ? wrote: >> > Hi Sergei, >> > we started to build our documentation with open source tools in R13B03 so it >> > would be possible to build the doc from the delivered sources. >> > >> > But it's still only built in house because we hadn't time to test it but the plan is >> > to have it work for everyone in R13B04. >> > >> > Thanks for your report, we'll have a look at those fault. >> > >> > Regards Lars >> > >> > >> > Sergei Golovan wrote: >> >> Hi! >> >> >> >> I'm trying to build Erlang documentation from the sources (the goal is >> >> to switch from prebuilt docs for Debian Erlang packages as building >> >> them from the source is preferable). >> >> >> >> To do that I run >> >> make >> >> make TYPE=docs >> >> (in fact, make libs doesn't recognize TYPE, so I had to replace "make >> >> opt" by "make $(TYPE) in the top-level Makefile). >> >> >> >> and I've found several problems which make build fail: >> >> >> >> 1) For some XML files (e.g. erts/docs/src/book.xml) xsltproc reports >> >> runtime errors about undefined variables (partnum in line 871 and 963 >> >> of db_pdf.xsl, in lines 1075 and 1173 of db_html.xsl). Is this a bug >> >> in the stylesheets or in xsltproc? (Both 1.1.24 from Debian stable and >> >> 1.1.26 from Debian unstable failed.) >> >> >> >> 2) wx application has duplicated targets html and docs in its makefile. >> >> >> >> 3) wx application (and others too) require docb_gen script to generate >> >> XML docs sources. It is missing. (I suppose that it is a simple >> >> wrapper around docb_gen Erlang module and could be recreated, but It'd >> >> be better if it were shipped in Erlang sources.) >> >> >> >> Is Erlang documentation supposed to be buildable from the source, or >> >> it still requires some unavailable tools? >> >> >> >> Cheers! >> > >> > >> >> >> >> ________________________________________________________________ >> erlang-bugs mailing list. See http://www.erlang.org/faq.html >> erlang-bugs (at) erlang.org > > > ________________________________________________________________ > erlang-bugs mailing list. See http://www.erlang.org/faq.html > erlang-bugs (at) erlang.org > > From dgud@REDACTED Wed Dec 16 17:44:59 2009 From: dgud@REDACTED (Dan Gudmundsson) Date: Wed, 16 Dec 2009 17:44:59 +0100 Subject: [erlang-bugs] [R13B02] Error message and duplicate menu item after debugger:start() on Mac OS X 10.6.1 In-Reply-To: References: Message-ID: <93df43b60912160844ia531849h969fce4ac58144f@mail.gmail.com> I have fixed some issues (e.g. the help menu) in the 'dgud/dbg_mac_menu' branch. And as I said in the mail off the list (reply-all is hard to remember) we can't do much about the menu warning. Mac's don't like gui's from console programs, but I don't think it's a real problem I havn't seen any crashes that I think is caused by that. /Dan On Tue, Dec 15, 2009 at 1:36 PM, Bruno Rijsman wrote: > The following bug was observed running Erlang R13B02 on Mac OS X 10.6.1 > > Start an erl shell: > erl > > Start the debugger: > debugger:start(). > > The debugger window opens. > > At this point in time the menu items for the debugger window are: beam.smp, > File, Edit, Module, Process, Break, Options, Windows, Help, Window. > > Click on the Help menu item. A drop down menu with the options Search and > Debugger appears. > > In the Erl shell the following error message appears: > > 2009-12-15 07:18:10.894 beam.smp[2675:3903] Calling -[NSMenuItemViewer > _getMenuItemViewerHIViewClassRegisteringIfNecessary] off the main thread. > This is not supported and will likely crash. > > The menu changes and now includes the following items: beam.smp, File, Edit, > Module, Process, Break, Options, Windows, Help, Window, Help. > > Note that the Help item is present twice. The first Help item has a drop > down menu with a single item Debugger. The second Help item has a drop down > menu with a single item Search. > From vladdu55@REDACTED Fri Dec 18 14:52:06 2009 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Fri, 18 Dec 2009 14:52:06 +0100 Subject: Documentation contains "\011" instead of tabs Message-ID: <95be1d3b0912180552vb0e944ek93ef872fba0644f9@mail.gmail.com> Hi, I noticed in quite a lot of places in the docs that instead of tabs, the string \011 is present. In some places there should be no tab at all (for example the docs for orber:install/1,2), in others (like in code snippets) it is meaningful. In my editor, just replacing \011 with a TAB gives misalignments, so I'm not sure if I would be able to make everything line up nicely, so I don't provide a patch. If you would like one anyway, let me know. best regards, Vlad From sgolovan@REDACTED Sat Dec 19 21:58:30 2009 From: sgolovan@REDACTED (Sergei Golovan) Date: Sat, 19 Dec 2009 23:58:30 +0300 Subject: [erlang-bugs] Building docs for R13B-03 fails In-Reply-To: <4B26025D.9020904@erix.ericsson.se> References: <4B26025D.9020904@erix.ericsson.se> Message-ID: Hi again! It seems that XSLT stylesheets which were used to generate Erlang R13B03 manpages are a bit buggy. The main problem is that in the generated manpages lines often start with dot (.) or apostrophe ('). These characters start groff macros, so some info will be lost after manpage formatting. Also, tools like apropos don't understand the APPLICATION or MODULE sections and try to find the NAME one. Another minor bug is incorrect authors information formatting. The attached patch simply makes xsltproc add \& before all dot and apostrophe symbols, and replaces MODULE by NAME header, and adds some authors processing. To check for bugs the following command can be used: LANG=C MANWIDTH=80 man --warnings -l filename.3 >/dev/null On Mon, Dec 14, 2009 at 12:16 PM, wrote: > Hi Sergei, > we started to build our documentation with open source tools in R13B03 so it > would be possible to build the doc from the delivered sources. > > But it's still only built in house because we hadn't time to test it but the plan is > to have it work for everyone in R13B04. > > Thanks for your report, we'll have a look at those fault. > > Regards Lars > > > Sergei Golovan wrote: >> Hi! >> >> I'm trying to build Erlang documentation from the sources (the goal is >> to switch from prebuilt docs for Debian Erlang packages as building >> them from the source is preferable). >> >> To do that I run >> make >> make TYPE=docs >> (in fact, make libs doesn't recognize TYPE, so I had to replace "make >> opt" by "make $(TYPE) in the top-level Makefile). >> >> and I've found several problems which make build fail: >> >> 1) For some XML files (e.g. erts/docs/src/book.xml) xsltproc reports >> runtime errors about undefined variables (partnum in line 871 and 963 >> of db_pdf.xsl, in lines 1075 and 1173 of db_html.xsl). Is this a bug >> in the stylesheets or in xsltproc? (Both 1.1.24 from Debian stable and >> 1.1.26 from Debian unstable failed.) >> >> 2) wx application has duplicated targets html and docs in its makefile. >> >> 3) wx application (and others too) require docb_gen script to generate >> XML docs sources. It is missing. (I suppose that it is a simple >> wrapper around docb_gen Erlang module and could be recreated, but It'd >> be better if it were shipped in Erlang sources.) >> >> Is Erlang documentation supposed to be buildable from the source, or >> it still requires some unavailable tools? >> >> Cheers! > > -- Sergei Golovan -------------- next part -------------- A non-text attachment was scrubbed... Name: docs.patch Type: application/octet-stream Size: 5032 bytes Desc: not available URL: From sgolovan@REDACTED Sun Dec 20 06:47:49 2009 From: sgolovan@REDACTED (Sergei Golovan) Date: Sun, 20 Dec 2009 08:47:49 +0300 Subject: [erlang-bugs] Building docs for R13B-03 fails In-Reply-To: References: <4B26025D.9020904@erix.ericsson.se> Message-ID: Hi again! And another issue with Erlang manpages: Erlang places manpages for its config files into section 4 and application descriptions into section 6. Though man manual says that section 4 is for "special files (usually found in /dev)" and section 6 is for "games" (?!). I'd say that config files manpages are to be in section 5 "file formats and conventions" and applications - in section 7 (just don't fit any other section). Would it be too hard to move manpages across sections (This will require some minor changes to Erlang mode as well)? Or Erlang users expect them in sections 4 and 6, so they couldn't find them elsewhere? On Sat, Dec 19, 2009 at 11:58 PM, Sergei Golovan wrote: > Hi again! > > It seems that XSLT stylesheets which were used to generate Erlang > R13B03 manpages are a bit buggy. The main problem is that in the > generated manpages lines often start with dot (.) or apostrophe ('). > These characters start groff macros, so some info will be lost after > manpage formatting. > > Also, tools like apropos don't understand the APPLICATION or MODULE > sections and try to find the NAME one. > > Another minor bug is incorrect authors information formatting. > > The attached patch simply makes xsltproc add \& before all dot and > apostrophe symbols, and replaces MODULE by NAME header, and adds some > authors processing. > > To check for bugs the following command can be used: > LANG=C MANWIDTH=80 man --warnings -l filename.3 >/dev/null > > On Mon, Dec 14, 2009 at 12:16 PM, ? wrote: >> Hi Sergei, >> we started to build our documentation with open source tools in R13B03 so it >> would be possible to build the doc from the delivered sources. >> >> But it's still only built in house because we hadn't time to test it but the plan is >> to have it work for everyone in R13B04. >> >> Thanks for your report, we'll have a look at those fault. >> >> Regards Lars >> >> >> Sergei Golovan wrote: >>> Hi! >>> >>> I'm trying to build Erlang documentation from the sources (the goal is >>> to switch from prebuilt docs for Debian Erlang packages as building >>> them from the source is preferable). >>> >>> To do that I run >>> make >>> make TYPE=docs >>> (in fact, make libs doesn't recognize TYPE, so I had to replace "make >>> opt" by "make $(TYPE) in the top-level Makefile). >>> >>> and I've found several problems which make build fail: >>> >>> 1) For some XML files (e.g. erts/docs/src/book.xml) xsltproc reports >>> runtime errors about undefined variables (partnum in line 871 and 963 >>> of db_pdf.xsl, in lines 1075 and 1173 of db_html.xsl). Is this a bug >>> in the stylesheets or in xsltproc? (Both 1.1.24 from Debian stable and >>> 1.1.26 from Debian unstable failed.) >>> >>> 2) wx application has duplicated targets html and docs in its makefile. >>> >>> 3) wx application (and others too) require docb_gen script to generate >>> XML docs sources. It is missing. (I suppose that it is a simple >>> wrapper around docb_gen Erlang module and could be recreated, but It'd >>> be better if it were shipped in Erlang sources.) >>> >>> Is Erlang documentation supposed to be buildable from the source, or >>> it still requires some unavailable tools? >>> >>> Cheers! >> >> > > > > -- > Sergei Golovan > -- Sergei Golovan From rory@REDACTED Sun Dec 20 21:16:18 2009 From: rory@REDACTED (Rory Byrne) Date: Sun, 20 Dec 2009 21:16:18 +0100 Subject: public_key documentation error - should read 'not_encrypted' Message-ID: <20091220201618.GA11366@almeida.jinsky.com> Hi, In the descriptions of pem_to_der/1 and decode_private_key/1,2 in the public_key application, it says that CipherInfo can be the atom 'no_encryption'. This is incorrect, it is actually the atom 'not_encrypted'. I've attached a patch, but it's not tested [1]. Thanks, Rory [1] I couldn't get the release docs from github to build. Something about variable 'partnum' not been declared in .../db_pdf.xsl (line 870). Probably just down to my setup. -------------- next part -------------- A non-text attachment was scrubbed... Name: public_key-doc-fix.diff Type: text/x-diff Size: 2437 bytes Desc: not available URL: From sam@REDACTED Mon Dec 21 07:02:08 2009 From: sam@REDACTED (Sam Bobroff) Date: Mon, 21 Dec 2009 17:02:08 +1100 Subject: Incomplete processing of "-eval" with closed stdin Message-ID: <4B2F0F60.8050008@m5net.com> Hi, I recently found that a small script of mine, run by passing Erlang code as an argument to "erl -eval", was failing when run by cron. I could easily reproduce the problem on the command line using this example: $ erl -eval 'io:fwrite("before\n"), receive after 1000 -> ok end, io:fwrite("after\n"), init:stop().' < /dev/null Eshell V5.7.4 (abort with ^G) before 1> *** Terminating erlang (nonode@REDACTED) It seems like init is terminating the VM as soon as it detects that stdin is closed, which is almost immediately. Obviously my script should have had "-noshell" and adding it fixes the problem. However, it does seem like a bug that the code passed by -eval is cut off while still executing. Perhaps "-noshell" should be applied automatically when erl is started with stdin already closed? I'm using R13B03. Sam. -- Sam Bobroff | sam@REDACTED | M5 Networks Why does my email have those funny headers? Because I use PGP to sign my email (and you should too!): that's how you know it's really from me. See: http://en.wikipedia.org/wiki/Pretty_Good_Privacy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature URL: From lars@REDACTED Mon Dec 21 10:08:20 2009 From: lars@REDACTED (Lars Thorsen) Date: Mon, 21 Dec 2009 10:08:20 +0100 Subject: [erlang-bugs] Building docs for R13B-03 fails In-Reply-To: References: <4B26025D.9020904@erix.ericsson.se> Message-ID: <4B2F3B04.2010905@erix.ericsson.se> Hi Sergei, someone in the beginning of OTP history decided to place them there and I don' remember why. I don't know if Erlang users expect them to be there but they have at least got used to it :). I think your suggestion is appropriate and we'll look at it but I don't know if we change. Regards Lars Erlang/OTP, Ericsson AB Sergei Golovan wrote: > Hi again! > > And another issue with Erlang manpages: > > Erlang places manpages for its config files into section 4 and > application descriptions into section 6. Though man manual says that > section 4 is for "special files (usually found in /dev)" and section 6 > is for "games" (?!). > > I'd say that config files manpages are to be in section 5 "file > formats and conventions" and applications - in section 7 (just don't > fit any other section). > > Would it be too hard to move manpages across sections (This will > require some minor changes to Erlang mode as well)? Or Erlang users > expect them in sections 4 and 6, so they couldn't find them elsewhere? > From nick@REDACTED Wed Dec 23 15:12:57 2009 From: nick@REDACTED (Niclas Eklund) Date: Wed, 23 Dec 2009 15:12:57 +0100 (CET) Subject: [erlang-bugs] Documentation contains "\011" instead of tabs In-Reply-To: <95be1d3b0912180552vb0e944ek93ef872fba0644f9@mail.gmail.com> References: <95be1d3b0912180552vb0e944ek93ef872fba0644f9@mail.gmail.com> Message-ID: Hello! These has obviously been around for quite some time and surfaced when the doc-builder tool was changed. This has already been fixed for some applications but will try to correct the remaining applications as soon as possible. Hence, a patch is not required, but thanks anyway. Best Regards, Niclas @ Erlang/OTP On Fri, 18 Dec 2009, Vlad Dumitrescu wrote: > Hi, > > I noticed in quite a lot of places in the docs that instead of tabs, > the string \011 is present. In some places there should be no tab at > all (for example the docs for orber:install/1,2), in others (like in > code snippets) it is meaningful. > > In my editor, just replacing \011 with a TAB gives misalignments, so > I'm not sure if I would be able to make everything line up nicely, so > I don't provide a patch. If you would like one anyway, let me know. > > best regards, > Vlad > > ________________________________________________________________ > erlang-bugs mailing list. See http://www.erlang.org/faq.html > erlang-bugs (at) erlang.org > From aude.quintana@REDACTED Wed Dec 23 16:47:20 2009 From: aude.quintana@REDACTED (aude quintana) Date: Wed, 23 Dec 2009 16:47:20 +0100 Subject: R13B03 makes SSL handshake fail (bug in OTP-PUB-KEY.erl). In-Reply-To: References: Message-ID: Hello everybody, Since the R13B03 release I have a problem with OTP-PUB-KEY.erl : SSL handshake makes it bug. It doens't accept certificates and other pem file any more. The error is a case clause bug in decode/2. I found the bug, the decode/2 function is like this : decode(Type, Data) -> ? ?case catch decode(Data) of ? ? ?{error, incomplete} -> {error, incomplete}; ? ? ?{Data, _Rest} -> ? ? ? ? ?case catch decode_disp(Type, Data) of ? ? ? ? ? ?{error, incomplete} -> {error, incomplete}; ? ? ? ? ? ?{'EXIT', {error, Reason}} -> {error, Reason}; ? ? ? ? ? ?{'EXIT', Reason} -> {error, {asn1, Reason}}; ? ? ? ? ? ?Result -> {ok, Result} ? ? ? ? ?end ? ?end. And decode(Data) when Data is a binary return something different from Data. So the {Data, _Rest} never match whereas the result of decode(Data) is right, so this is the case clause error. I patched this file (replacing Data with Data0 in function argument and in decode argument), and the problem disappeared. I joined the patch but here is the corrected decode function (it's the only change from the patch). : decode(Type, Data0) -> ? ?case catch decode(Data0) of ? ? ?{error, incomplete} -> {error, incomplete}; ? ? ?{Data, _Rest} -> ? ? ? ? ?case catch decode_disp(Type, Data) of ? ? ? ? ? ?{error, incomplete} -> {error, incomplete}; ? ? ? ? ? ?{'EXIT', {error, Reason}} -> {error, Reason}; ? ? ? ? ? ?{'EXIT', Reason} -> {error, {asn1, Reason}}; ? ? ? ? ? ?Result -> {ok, Result} ? ? ? ? ?end ? ?end. But this patch is not enough : OTP-PUB-KEY.erl is a generated file. I found the gen file (probably asn1ct_gen.erl and asn1ct_gen_ber_bin_v2.erl). The problem can be solved if OTP-PUB-KEY.asn1 is generated with undec_rest option. I tried to add this option in the Makefile (otp_src_R13B03/lib/public_key/asn1/Makefile), it had a right effect on decode/2 but it added some bugs on others functions. So now, I have no time to properly fix this bug. I continue with my patch and I hope someone will find the way to fix the bug from the asn1 gen files. Best Regards, -- Aude Quintana Mobile Devices -------------- next part -------------- A non-text attachment was scrubbed... Name: OTP-PUB-KEY.diff Type: text/x-patch Size: 608 bytes Desc: not available URL: From aude.quintana@REDACTED Wed Dec 23 17:08:47 2009 From: aude.quintana@REDACTED (aude quintana) Date: Wed, 23 Dec 2009 17:08:47 +0100 Subject: R13B03 makes SSL handshake fail (bug in OTP-PUB-KEY.erl). In-Reply-To: References: Message-ID: Ooooops mea culpa, this is my bug, it dont't know why but I compiled otp from source that I modified before. So there is no bug. Sorry again. 2009/12/23 aude quintana : > Hello everybody, > Since the R13B03 release I have a problem with OTP-PUB-KEY.erl : SSL > handshake makes it bug. > It doens't accept certificates and other pem file any more. > The error is a case clause bug in decode/2. > > I found the bug, the decode/2 function is like this : > decode(Type, Data) -> > ? ?case catch decode(Data) of > ? ? ?{error, incomplete} -> {error, incomplete}; > ? ? ?{Data, _Rest} -> > ? ? ? ? ?case catch decode_disp(Type, Data) of > ? ? ? ? ? ?{error, incomplete} -> {error, incomplete}; > ? ? ? ? ? ?{'EXIT', {error, Reason}} -> {error, Reason}; > ? ? ? ? ? ?{'EXIT', Reason} -> {error, {asn1, Reason}}; > ? ? ? ? ? ?Result -> {ok, Result} > ? ? ? ? ?end > ? ?end. > > And decode(Data) when Data is a binary return something different from Data. > So the {Data, _Rest} never match whereas the result of decode(Data) is right, > so this is the case clause error. > > I patched this file (replacing Data with Data0 in function argument > and in decode argument), and the problem disappeared. > I joined the patch but here is the corrected decode function (it's the > only change from the patch). : > decode(Type, Data0) -> > ? ?case catch decode(Data0) of > ? ? ?{error, incomplete} -> {error, incomplete}; > ? ? ?{Data, _Rest} -> > ? ? ? ? ?case catch decode_disp(Type, Data) of > ? ? ? ? ? ?{error, incomplete} -> {error, incomplete}; > ? ? ? ? ? ?{'EXIT', {error, Reason}} -> {error, Reason}; > ? ? ? ? ? ?{'EXIT', Reason} -> {error, {asn1, Reason}}; > ? ? ? ? ? ?Result -> {ok, Result} > ? ? ? ? ?end > ? ?end. > > But this patch is not enough : OTP-PUB-KEY.erl is a generated file. I > found the gen file (probably asn1ct_gen.erl and > asn1ct_gen_ber_bin_v2.erl). The problem can be solved if > OTP-PUB-KEY.asn1 is generated with undec_rest option. I tried to add > this option in the Makefile > (otp_src_R13B03/lib/public_key/asn1/Makefile), it had a right effect > on decode/2 but it added some bugs on others functions. > So now, I have no time to properly fix this bug. I continue with my > patch and I hope someone will find the way to fix the bug from the > asn1 gen files. > > Best Regards, > -- > Aude Quintana > Mobile Devices > -- Aude Quintana Mobile Devices +33 (0) 630 790 419 From pguyot@REDACTED Wed Dec 23 18:40:45 2009 From: pguyot@REDACTED (Paul Guyot) Date: Wed, 23 Dec 2009 18:40:45 +0100 Subject: relup always starts new applications permanently Message-ID: Hello, I think I've encountered a bug in relup generation. If a new application appears in the rel file, make_relup generates an add_application primitive, which in turn generates a line which is always like : {apply,{application,start,[new_application,permanent]}} systools_relup and systools_rc:translate_application_instrs/3 (line 326) However, the new application might have a different start type in the new .rel file. In some cases, it may even be loaded only (and not started). I believe we might need a new option in the add_application primitive to include the start type and translate this type accordingly with : permanent -> {apply,{application,start,[Application,permanent]}} transient -> {apply,{application,start,[Application,transient]}} temorary -> {apply,{application,start,[Application,temporary]}} load -> {apply,{application,load,[Application]}} none -> just nothing Regards, Paul -- Semiocast http://titema.com/ +33.175000290 - 62 bis rue Gay-Lussac, 75005 Paris From pguyot@REDACTED Wed Dec 23 18:47:55 2009 From: pguyot@REDACTED (Paul Guyot) Date: Wed, 23 Dec 2009 18:47:55 +0100 Subject: .config file overwritten during releases Message-ID: Hello, When performing a release in interactive mode, the sys.config file that comes with the release is consulted (if any), but any value defined in the config file(s) passed with the -config parameter to erl are lost. I believe this is not an intended behaviour. At least, the config(4) man page isn't explicit about this. The problem is in release_handler:change_appl_data/3. Paul -- Semiocast http://titema.com/ +33.175000290 - 62 bis rue Gay-Lussac, 75005 Paris From nesrait@REDACTED Mon Dec 28 00:46:23 2009 From: nesrait@REDACTED (=?ISO-8859-1?Q?Davide_Marqu=EAs?=) Date: Sun, 27 Dec 2009 23:46:23 +0000 Subject: open_port cd PortSetting not working on windows Message-ID: <523869a70912271546j60b19704we87891d6ceedaee6@mail.gmail.com> Hi all, Just found out that the open_port {cd, Dir} PortSetting isn't working on windows. The following shell interaction show the problem in R13B03: > Eshell V5.7.4 (abort with ^G) > 1> > open_port({spawn_executable,"d:/Projectos/ewgi_examples/priv/www/cgi_index/index.exe"}, > []). > #Port<0.509> > 2> open_port({spawn_executable,"./index.exe"}, > [{cd,"d:/Projectos/ewgi_examples/priv/www/cgi_index"}]). > ** exception error: enoent > in function open_port/2 > called as open_port({spawn_executable,"./index.exe"}, > > [{cd,"d:/Projectos/ewgi_examples/priv/www/cgi_index"}]) > 3> cd("d:/Projectos/ewgi_examples/priv/www/cgi_index"). > d:/Projectos/ewgi_examples/priv/www/cgi_index > ok > 4> open_port({spawn_executable,"./index.exe"}, []). > #Port<0.526> > Bug also spotted on R13B01/2. Cheers, Davide From steven.charles.davis@REDACTED Tue Dec 29 09:13:46 2009 From: steven.charles.davis@REDACTED (Steve Davis) Date: Tue, 29 Dec 2009 02:13:46 -0600 Subject: gen_udp behaviour Message-ID: <4B39BA3A.6010305@gmail.com> Frankly, I'm not clear on what the solution to the following situation should be from the OTP side, *if any*, but I thought I should at least report this edge-case behaviour. I'm communicating with a badly behaved UDP server that is unpredictably appending additional bytes to sent udp packets beyond the declared payload length. Example capture from WireShark: --- Frame 1203 (60 bytes on wire, 60 bytes captured) User Datagram Protocol, Src Port: 12035 (12035), Dst Port: oc-lm (1448) Source port: 12035 (12035) Destination port: oc-lm (1448) Length: 23 Checksum: 0xb2a0 [correct] Data (15 bytes) Data: 000000000100FFFFFFFB0101000000 0000 00 c0 9f 7f 26 c2 00 c0 49 db ac d0 08 00 45 00 ....&...I.....E. 0010 00 2b 00 00 40 00 38 11 2c 4b d8 52 02 16 c0 a8 .+..@REDACTED,K.R.... 0020 7b 66 2f 03 05 a8 00 17 b2 a0 00 00 00 00 01 00 {f/............. 0030 ff ff ff fb 01 01 00 00 00 00 00 00 ............ --- As you can see, the actual payload length is correctly set for the message, but the server has chosen (in this case) to append three additional zero bytes. Rather than just the 15 bytes of data, gen_udp is returning the data plus the erroneous extra bytes - i.e. a total of 18 bytes that were actually sent over the wire. The reason this has caused me a development issue is that without knowing the length specified in the UDP packet header it's makes it tough to parse some messages from this incorrectly-implemented server reliably. What the solution to this should be -- I'm not entirely sure. Regards, Steve From bengt.kleberg@REDACTED Tue Dec 29 10:49:03 2009 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Tue, 29 Dec 2009 10:49:03 +0100 Subject: [erlang-bugs] gen_udp behaviour In-Reply-To: <4B39BA3A.6010305@gmail.com> References: <4B39BA3A.6010305@gmail.com> Message-ID: <1262080143.7577.17.camel@seasc1137.dyn.rnd.as.sw.ericsson.se> Greetings, I would suggest that gen_udp only sends the number of bytes specified in the UDP packet header. If backwards compatibility mandates that the current behaviour is maintained for existing applications, then a flag could turn on the new (correct) behaviour. Add to open/2 options something like this: {receive_correct_length, true} bengt On Tue, 2009-12-29 at 02:13 -0600, Steve Davis wrote: > Frankly, I'm not clear on what the solution to the following situation > should be from the OTP side, *if any*, but I thought I should at least > report this edge-case behaviour. > > I'm communicating with a badly behaved UDP server that is unpredictably > appending additional bytes to sent udp packets beyond the declared > payload length. > > Example capture from WireShark: > --- > Frame 1203 (60 bytes on wire, 60 bytes captured) > User Datagram Protocol, Src Port: 12035 (12035), Dst Port: oc-lm (1448) > Source port: 12035 (12035) > Destination port: oc-lm (1448) > Length: 23 > Checksum: 0xb2a0 [correct] > Data (15 bytes) > Data: 000000000100FFFFFFFB0101000000 > > 0000 00 c0 9f 7f 26 c2 00 c0 49 db ac d0 08 00 45 00 ....&...I.....E. > 0010 00 2b 00 00 40 00 38 11 2c 4b d8 52 02 16 c0 a8 .+..@REDACTED,K.R.... > 0020 7b 66 2f 03 05 a8 00 17 b2 a0 00 00 00 00 01 00 {f/............. > 0030 ff ff ff fb 01 01 00 00 00 00 00 00 ............ > --- > > As you can see, the actual payload length is correctly set for the > message, but the server has chosen (in this case) to append three > additional zero bytes. > > Rather than just the 15 bytes of data, gen_udp is returning the data > plus the erroneous extra bytes - i.e. a total of 18 bytes that were > actually sent over the wire. > > The reason this has caused me a development issue is that without > knowing the length specified in the UDP packet header it's makes it > tough to parse some messages from this incorrectly-implemented server > reliably. > > What the solution to this should be -- I'm not entirely sure. > > Regards, > Steve > > > ________________________________________________________________ > erlang-bugs mailing list. See http://www.erlang.org/faq.html > erlang-bugs (at) erlang.org > From mickael.remond@REDACTED Thu Dec 31 12:27:42 2009 From: mickael.remond@REDACTED (=?iso-8859-1?Q?Micka=EBl_R=E9mond?=) Date: Thu, 31 Dec 2009 12:27:42 +0100 Subject: epmd not cleaning up node name if node is down. Click to flag this post Message-ID: Hello, I have found this message from the archive: By Zbyszek ???kiewski Aug 15, 2008: > Hello, > > I have noticed that epmd is not cleaning node names if there are multiple nodes running on the same system and one of the node is shuted down. > When i try to run node (jggtrans) In logs i can see: > > Aug 15 12:22:05 xmpp epmd: epmd: epmd running - daemon = 1 > Aug 15 12:22:05 xmpp epmd: epmd: node name already occupied jggtrans > Aug 15 12:22:46 xmpp epmd: epmd: epmd running - daemon = 1 > Aug 15 12:22:46 xmpp epmd: epmd: node name already occupied jggtrans > > epmd - name: > > epmd: up and running on port 4369 with data: > name jggtrans at port 46477 > name zero at port 58591 We find that this problem happens more and more often. It is reproducible very often on Amazon deployments for example. The only solution is to kill epmd in this situation, otherwise you are stuck with a duplicate name. If you have other Erlang VM running on the same machine in cluster, you are out of luck because, you have to restart all Erlang VM. Do you need help to investigate on this problem ? Thank you ! -- Micka?l R?mond http://www.process-one.net/