From by@REDACTED Wed Jan 1 10:55:06 2020 From: by@REDACTED (by) Date: Wed, 1 Jan 2020 17:55:06 +0800 Subject: Only install manual pages (install-docs) Message-ID: <36E9BFCC-AF93-4A95-8DE8-3FA020DF808D@meetlost.com> Hi, I build Erlang from source, and use "make install-docs" to install the docs. I am happy with this, but seems the process of ?make install-docs? takes a few minutes, and mostly, the docs which I used daily is the manual pages. I am wondering any existing method to constrain the ?install-docs? command to only install/touch the manual pages? Kind Regards, Yao From v.levytskyy@REDACTED Wed Jan 1 16:26:03 2020 From: v.levytskyy@REDACTED (Vyacheslav Levytskyy) Date: Wed, 1 Jan 2020 16:26:03 +0100 Subject: Matching fun M:F/A In-Reply-To: References: Message-ID: <3629d850-83a2-1a41-cc6a-242b4474e99e@yahoo.com> Hello, you can match MFA like the following: test(Pred) -> ??? test1(Pred, fun lists:keysearch/3). test1(F, F) -> ??? match; test1(_, _) -> ??? nomatch. Erlang shell: 3> tonic_test:test(fun lists:keysearch/3). match 4> tonic_test:test(fun lists:member/2). nomatch It looks like function expression is not a pattern expression in the grammar (pat_expr), and erl_lint identifies it eventually as an illegal pattern. Best regards, Vyacheslav On 31.12.2019 17:12, Pierre Fenoll wrote: > Hi, > > Since a few releases, the value fun M:F/A (provided M, F & A are > bound) is a literal. It can be read with file:consult/1 as well as > erlang:binary_to_term/1. > > Running OTP 22, funs can be compared: > > eq(F) -> > ? ? %% Compiles & works as expected. > ? ? F == fun lists:keysearch/3. > > However MFAs cannot be matched: > > %% syntax error before: 'fun' > fmatch(fun lists:keysearch/3) -> true; > fmatch(_) -> false. > > cmatch(F) -> > ? ? case F of > ? ? ? ? %% illegal pattern > ? ? ? ? fun lists:keysearch/3 -> true; > ? ? ? ? %% illegal guard expression > ? ? ? ? X when X == fun lists:keysearch/3 -> true; > > ? ? ? ? %% illegal pattern > ? ? ? ? fun lists:_/3 -> inte; > ? ? ? ? fun _:handle_cast/2 -> resting; > ? ? ? ? _ -> false > ? ? end. > > Is this intended? > > I believe it would be interesting to allow such patterns as well as > for fun _:_/_. > This could help in optimization through specialization and probably > would make for some new approaches. > Among all funs only fully qualified funs can be expressed this way so > this behaviour could be a bit surprising to some but MFAs are already > comparable today so I'd say we're already halfway there. > > Thoughts? > > PS: it seems one is no longer able to log into bugs.erlang.org > with GitHub credentials as > https://bugs.erlang.org/login.jsp?os_destination=%2Fdefault.jsp?doesn't > provide the option anymore. Is this normal? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikpelinux@REDACTED Thu Jan 2 10:28:05 2020 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Thu, 2 Jan 2020 10:28:05 +0100 Subject: Matching fun M:F/A In-Reply-To: References: Message-ID: On Tue, Dec 31, 2019 at 5:12 PM Pierre Fenoll wrote: > > Hi, > > Since a few releases, the value fun M:F/A (provided M, F & A are bound) is a literal. It can be read with file:consult/1 as well as erlang:binary_to_term/1. > > Running OTP 22, funs can be compared: > > eq(F) -> > %% Compiles & works as expected. > F == fun lists:keysearch/3. > > However MFAs cannot be matched: > > %% syntax error before: 'fun' > fmatch(fun lists:keysearch/3) -> true; > fmatch(_) -> false. > > cmatch(F) -> > case F of > %% illegal pattern > fun lists:keysearch/3 -> true; > %% illegal guard expression > X when X == fun lists:keysearch/3 -> true; > > %% illegal pattern > fun lists:_/3 -> inte; > fun _:handle_cast/2 -> resting; > _ -> false > end. > > Is this intended? > > I believe it would be interesting to allow such patterns as well as for fun _:_/_. > This could help in optimization through specialization and probably would make for some new approaches. > Among all funs only fully qualified funs can be expressed this way so this behaviour could be a bit surprising to some but MFAs are already comparable today so I'd say we're already halfway there. I believe this is mostly a historical accident. Erlang started out as a first-order language, and functional values were a later addition (made in several increments I believe). Also, functional values are mostly opaque while pattern-matching is entirely about determining the shape of non-opaque types, so I'm not surprised that fun M:F/A like patterns aren't supported. Having said that, there's no inherent reason why fun M:F/A couldn't be a pattern, but the effort required to implement it would be substantial, and I question how much real-world value it would provide. A slightly |ower-cost alternative that would still be useful would be to make fun_info/2 a guard BIF, but in that case it should return the requested value directly and not wrapped as a {Key,Value} tuple. The old is_function(F, A) would then be an alias for is_function(F), fun_info(F, arity) == A. From jesper.louis.andersen@REDACTED Thu Jan 2 13:40:55 2020 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Thu, 2 Jan 2020 13:40:55 +0100 Subject: Matching fun M:F/A In-Reply-To: References: Message-ID: On Tue, Dec 31, 2019 at 5:12 PM Pierre Fenoll wrote: > Thoughts? > > Admitting equality and by extension unification on function values is a dangerous game which you usually don't want to play. The reason is that equality often has to be tailored to the situation. Stake #1 in the vampire: Function equality is undecidable[0]. We can't generally handle this: F = fun(X) -> X + 3 end, G = fun(X) -> X + 2 + 1 end, F==G. though an optimizing compiler might decide to turn G into the exact same byte code instructions as F. Stake #2 in the vampire: reference equality is not very Erlang-like, but it gives you *some* equality over the function domain. We tend to test equality by value only. Stake #3 in the vampire: sensible languages outright *reject* equality on certain types. And by extension, not all types can be compared in the usual sense. Stake #4 in the vampire: you often want to equip several different types of equality to a type[1] [0] Sketch of proof: reduce to a solution to the halting problem. Also see Rice's theorem. [1] Classic Haskell98 has a couple of weaknesses here. If you implement Eq, then you cannot easily implement another kind of Eq for the same type unless you newtype-wrap it. It is also prevalent in the Ord class with orders. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Thu Jan 2 17:17:48 2020 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Thu, 2 Jan 2020 17:17:48 +0100 Subject: Nine Nines The Erlanger Playbook In-Reply-To: References: Message-ID: <0b347805-ddc7-47e6-09a5-f9378631e371@ninenines.eu> Hello, You can send me an email directly for questions like this, this isn't my personal mailing list. But for what it's worth: I should be able to make the book available again Q1 or Q2 of 2020. This is an estimate, I currently don't know for sure. I am currently working on incorporating edits from Lloyd. Thanks Lloyd! This is clearly a slow process but it's definitely an improvement. I also cut down my expectations of what I want included. I now have a clear route to a final version. Right now I'm only looking into adding 3 more chapters and adding some more content to 5 others. This doesn't mean I won't add more content after that, there's topics I find really interesting and want to cover, but I had to draw the line somewhere. There's 2 chapters that have already been written in parts but are not essential. One is more useful than the other, but it's complex to write. I may include that chapter in the final version depending on time. Cheers, On 27/12/2019 12:47, I Gusti Ngurah Oka Prinarjaya wrote: > Hi Lo?c Hoguin, > > Woww.. I am very interested to buy your book. But when full version of > this book will available? > > Thanks > -- Lo?c Hoguin https://ninenines.eu From frank.muller.erl@REDACTED Thu Jan 2 17:37:55 2020 From: frank.muller.erl@REDACTED (Frank Muller) Date: Thu, 2 Jan 2020 17:37:55 +0100 Subject: Port locks with high time under LCNT In-Reply-To: References: Message-ID: Thanks to @Peti G?m?ri, I was able to identify these Port locks: https://gist.github.com/frankmullerl/008174c6594ca27584ac7f4e6724bee5 Some of them are taking up to 6.7sec (6707846 usec) :-/ My application is serving static images by calling file:sendfile/2 ( https://erlang.org/doc/man/file.html#sendfile-2). Can someone please explain how I can avoid these locks or at least make their impact lesser? /Frank Mon 30 dec. 2019 at 19:58, Frank Muller wrote: > I was able to find out which lock is used by run_queue: > https://gist.github.com/frankmullerl/008174c6594ca27584ac7f4e6724bee5 > > Question: how can I check the lock behind #Port for > example? > > /Frank > > Hi All >> >> My custom-made web server which only serves only static files (a la Hugo: >> https://gohugo.io/) is showing this under LCNT: >> https://gist.github.com/frankmullerl/008174c6594ca27584ac7f4e6724bee5 >> >> Can someone explain how to dig further to understand what?s going on and >> why these Port locks are taking so much time? >> >> /Frank >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikpelinux@REDACTED Thu Jan 2 21:37:31 2020 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Thu, 2 Jan 2020 21:37:31 +0100 Subject: Port locks with high time under LCNT In-Reply-To: References: Message-ID: On Thu, Jan 2, 2020 at 5:38 PM Frank Muller wrote: > > Thanks to @Peti G?m?ri, I was able to identify these Port locks: > https://gist.github.com/frankmullerl/008174c6594ca27584ac7f4e6724bee5 > > Some of them are taking up to 6.7sec (6707846 usec) :-/ > > My application is serving static images by calling file:sendfile/2 (https://erlang.org/doc/man/file.html#sendfile-2). > > Can someone please explain how I can avoid these locks or at least make their impact lesser? Using the file module has been known to cause synchronization overheads. Often we (Klarna) use prim_file instead, but it has sendfile/8 not /2. Anyway, that may be an avenue worth investigating. From frank.muller.erl@REDACTED Thu Jan 2 23:07:36 2020 From: frank.muller.erl@REDACTED (Frank Muller) Date: Thu, 2 Jan 2020 23:07:36 +0100 Subject: Port locks with high time under LCNT In-Reply-To: References: Message-ID: Hi Mikael Thanks for pointing out prim_inet. To my knowledge, it?s undocumented I can be changed by the OTP team. That?s why I?ve avoided it at the first place. By the way, you probably mean prim_inet:sendfile/4 not 8, correct? I made a quick the change to my app and found that the throughput is a little bit better (3% faster). But these port locks are still there :-/ Any other ideas? /Frank On Thu, Jan 2, 2020 at 5:38 PM Frank Muller wrote: > > > > Thanks to @Peti G?m?ri, I was able to identify these Port locks: > > https://gist.github.com/frankmullerl/008174c6594ca27584ac7f4e6724bee5 > > > > Some of them are taking up to 6.7sec (6707846 usec) :-/ > > > > My application is serving static images by calling file:sendfile/2 ( > https://erlang.org/doc/man/file.html#sendfile-2). > > > > Can someone please explain how I can avoid these locks or at least make > their impact lesser? > > Using the file module has been known to cause synchronization > overheads. Often we (Klarna) use prim_file instead, > but it has sendfile/8 not /2. Anyway, that may be an avenue worth > investigating. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dszoboszlay@REDACTED Fri Jan 3 00:15:37 2020 From: dszoboszlay@REDACTED (=?UTF-8?Q?D=C3=A1niel_Szoboszlay?=) Date: Fri, 3 Jan 2020 00:15:37 +0100 Subject: Matching fun M:F/A In-Reply-To: References: Message-ID: On Thu, 2 Jan 2020 at 13:41, Jesper Louis Andersen < jesper.louis.andersen@REDACTED> wrote: > Admitting equality and by extension unification on function values is a > dangerous game which you usually don't want to play. The reason is that > equality often has to be tailored to the situation. > > It may be a bit aside to the original topic, but I don't understand this argument. Erlang already defines equality of function values, even pattern matching works for them with the = operator. The proposal was not about (re)defining the semantics of these operations but making the language more consistent on where does it allow the use of them. Also, while it's true that function equality is undecidable, functions are not the only data type where the language's built-in equality and pattern matching are not tailored to the situation. In fact, it's quite common that complex data structures allow expressing the same value in different, unequal forms. For example both {[2],[1]} and {[],[1,2]} describe the same queue value, yet they won't compare equal. I believe this is something programmers are expected to understand and be aware of, and therefore they shall also understand and be aware of the limitations of the built-in function equality. Cheers, Daniel PS: I played a bit with function equality and pattern matching while writing my reply, and I personally found all but the last of these examples intuitive (by the way, they all work with = in place of =:= too): 1> F1 = fun lists:sort/1. fun lists:sort/1 2> F2 = fun lists:sort/1. fun lists:sort/1 3> F1 =:= F2. true 4> F = fun (X) -> F1([x | X]) end. #Fun 5> F =:= F. true 6> G = fun (X) -> F1([x | X]) end. #Fun 7> F =:= G. true 8> H = fun (X) -> F2([x | X]) end. #Fun 9> F =:= H. false For anyone curious, F and H are not equal because we're in the shell, and funs created in the shell will essentially take their source code in a free variable, which for H is the following tuple: {[{'F2',fun lists:sort/1}], {eval,#Fun}, {value,#Fun}, [{clause,1, [{var,1,'X'}], [], [{call,1,{var,1,'F2'},[{cons,1,{atom,1,x},{var,1,'X'}}]}]}]} Now it's obvious that while variables F1 and F2 are bound to the same function value and would compare equal, shell funs using them would also contain their variable names, which are different. -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank.muller.erl@REDACTED Fri Jan 3 00:40:01 2020 From: frank.muller.erl@REDACTED (Frank Muller) Date: Fri, 3 Jan 2020 00:40:01 +0100 Subject: Port locks with high time under LCNT In-Reply-To: References: Message-ID: The more load we have, the more locks contention we get: https://gist.github.com/frankmullerl/7fb9470e22869312d97011c0faf0046b /Frank Hi Mikael > > Thanks for pointing out prim_inet. To my knowledge, it?s undocumented I > can be changed by the OTP team. That?s why I?ve avoided it at the first > place. > > By the way, you probably mean prim_inet:sendfile/4 not 8, correct? > > I made a quick the change to my app and found that the throughput is a > little bit better (3% faster). > > But these port locks are still there :-/ > Any other ideas? > > /Frank > > On Thu, Jan 2, 2020 at 5:38 PM Frank Muller > wrote: > >> > >> > Thanks to @Peti G?m?ri, I was able to identify these Port locks: >> > https://gist.github.com/frankmullerl/008174c6594ca27584ac7f4e6724bee5 >> > >> > Some of them are taking up to 6.7sec (6707846 usec) :-/ >> > >> > My application is serving static images by calling file:sendfile/2 ( >> https://erlang.org/doc/man/file.html#sendfile-2). >> > >> > Can someone please explain how I can avoid these locks or at least make >> their impact lesser? >> >> Using the file module has been known to cause synchronization >> overheads. Often we (Klarna) use prim_file instead, >> but it has sendfile/8 not /2. Anyway, that may be an avenue worth >> investigating. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From okaprinarjaya@REDACTED Fri Jan 3 03:12:56 2020 From: okaprinarjaya@REDACTED (I Gusti Ngurah Oka Prinarjaya) Date: Fri, 3 Jan 2020 09:12:56 +0700 Subject: Nine Nines The Erlanger Playbook In-Reply-To: <0b347805-ddc7-47e6-09a5-f9378631e371@ninenines.eu> References: <0b347805-ddc7-47e6-09a5-f9378631e371@ninenines.eu> Message-ID: Hi, Awesome! Thanks Lo?c Pada tanggal Kam, 2 Jan 2020 pukul 23.17 Lo?c Hoguin menulis: > Hello, > > You can send me an email directly for questions like this, this isn't my > personal mailing list. > > But for what it's worth: I should be able to make the book available > again Q1 or Q2 of 2020. This is an estimate, I currently don't know for > sure. > > I am currently working on incorporating edits from Lloyd. Thanks Lloyd! > This is clearly a slow process but it's definitely an improvement. > > I also cut down my expectations of what I want included. I now have a > clear route to a final version. Right now I'm only looking into adding 3 > more chapters and adding some more content to 5 others. This doesn't > mean I won't add more content after that, there's topics I find really > interesting and want to cover, but I had to draw the line somewhere. > > There's 2 chapters that have already been written in parts but are not > essential. One is more useful than the other, but it's complex to write. > I may include that chapter in the final version depending on time. > > Cheers, > > On 27/12/2019 12:47, I Gusti Ngurah Oka Prinarjaya wrote: > > Hi Lo?c Hoguin, > > > > Woww.. I am very interested to buy your book. But when full version of > > this book will available? > > > > Thanks > > > > -- > Lo?c Hoguin > https://ninenines.eu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dszoboszlay@REDACTED Fri Jan 3 10:20:56 2020 From: dszoboszlay@REDACTED (=?UTF-8?Q?D=C3=A1niel_Szoboszlay?=) Date: Fri, 3 Jan 2020 10:20:56 +0100 Subject: Port locks with high time under LCNT In-Reply-To: References: Message-ID: Hi Frank, I think some context would help us to better understand your problem. For example what kind of problems do these lock conflicts cause in your system? Are there some Erlang processes that got stuck for several seconds? What are they trying to do at that time? Or is it only that the throughput you experience stays below your expectations? The lock stats in the gists don't seem that wrong to me. I don't have much experience with lock counters and can't figure out from the gists what do these ports are (the image files? tcp connections?) and how they are used, but my guess is they are the tcp connections. Each port lock is tried 4 or 5 times and there's only 1 (albeit often very long) collision. This is how I'd expect a web server to handle a tcp connection: do one read, one write, close it - a handful of operations only. And if you have an unresponsive client or bad network, one operation may easily take 6-7 seconds, blocking the next one. So just a guess, but is it possible you attempt to use the same tcp socket from two different processes? Cheers, Daniel On Fri, 3 Jan 2020 at 00:40, Frank Muller wrote: > The more load we have, the more locks contention we get: > > https://gist.github.com/frankmullerl/7fb9470e22869312d97011c0faf0046b > > /Frank > > > Hi Mikael >> >> Thanks for pointing out prim_inet. To my knowledge, it?s undocumented I >> can be changed by the OTP team. That?s why I?ve avoided it at the first >> place. >> >> By the way, you probably mean prim_inet:sendfile/4 not 8, correct? >> >> I made a quick the change to my app and found that the throughput is a >> little bit better (3% faster). >> >> But these port locks are still there :-/ >> Any other ideas? >> >> /Frank >> >> On Thu, Jan 2, 2020 at 5:38 PM Frank Muller >> wrote: >> >>> > >>> > Thanks to @Peti G?m?ri, I was able to identify these Port locks: >>> > https://gist.github.com/frankmullerl/008174c6594ca27584ac7f4e6724bee5 >>> > >>> > Some of them are taking up to 6.7sec (6707846 usec) :-/ >>> > >>> > My application is serving static images by calling file:sendfile/2 ( >>> https://erlang.org/doc/man/file.html#sendfile-2). >>> > >>> > Can someone please explain how I can avoid these locks or at least >>> make their impact lesser? >>> >>> Using the file module has been known to cause synchronization >>> overheads. Often we (Klarna) use prim_file instead, >>> but it has sendfile/8 not /2. Anyway, that may be an avenue worth >>> investigating. >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From duncan.attard.01@REDACTED Fri Jan 3 10:56:17 2020 From: duncan.attard.01@REDACTED (Duncan Paul Attard) Date: Fri, 3 Jan 2020 10:56:17 +0100 Subject: Obtain message content of Erlang messages in dtrace In-Reply-To: <5EA32E85-3F60-4B51-BF6F-8C887CDF5EE5@um.edu.mt> References: <498EF4E8-0C4E-4C3C-82C3-F509C6D16715@um.edu.mt> <5EA32E85-3F60-4B51-BF6F-8C887CDF5EE5@um.edu.mt> Message-ID: <924CB6C6-71D8-49BA-AA12-6E92C8CC5E5A@um.edu.mt> Hello, Just wanted to check on this. > On 16 Dec 2019, at 13:16, Duncan Paul Attard wrote: > > Thanks a lot! > > Yes, currently I?m using erlang:trace/3, but was curious whether the same thing can be achieved `externally` via dtrace (or even LTTng). > > Does `Dtrace is meant more to observe VM itself, not to trace you application.` mean that the message content cannot be retrieved though? > > Duncan > > >> On 16 Dec 2019, at 13:10, ?ukasz Niemier wrote: >> >>> I was experimenting with Erlang and dtrace, and am interested to know whether the message content exchanged between two Erlang processes can be obtained. In particular, I am interested in the `message-send` and `message-receive` probes. >> >> Dtrace is meant more to observe VM itself, not to trace you application. >> >>> Is there a way in which this can be achieved. And if not, are there any alternatives? >> >> For tracing your own application you have erlang:trace/3, seq_trace, dbg, dyntrace, etc. If you are more interested in tracing and debugging applications in Erlang then you should check https://www.erlang-in-anger.com >> >> -- >> >> ?ukasz Niemier >> lukasz@REDACTED >> >> >> >> >> > From frank.muller.erl@REDACTED Fri Jan 3 18:39:59 2020 From: frank.muller.erl@REDACTED (Frank Muller) Date: Fri, 3 Jan 2020 18:39:59 +0100 Subject: Port locks with high time under LCNT In-Reply-To: References: Message-ID: Hi Daniel Thanks for the feedback. Sorry for being unclear, but this thread discontinued when switched to 2020. I gave some context when I started it at: http://erlang.org/pipermail/erlang-questions/2019-December/098910.html More context: 1. I?m building a Hugo (https://gohugo.io/) like service in Erlang. Actually, it?s much more simpler than Hugo. You ask for a file, and you get it (or not). 2. The design is simple. One Erlang process handles one incoming connection. Thus, it?s not possible to mess up with TCP sockets here. Whether the file exists and gets delivered to the caller or not. 3. Average file size is ~150KB. Max file size: ~3MB 4. I?m using Erlang 22.2 on both Linux (prod system) and MacOS (dev). 5. The service is caping at 4'000 req/sec. 6. @Mikael Pettersson suggested to use prim_file:sendfile/8 which gaves us a boost of ~3% in throughput. 7. For now, I?m only using HTTP (no HTTPS). 8. Linux sysctl settings are good and tuned ( https://medium.com/@pawilon/tuning-your-linux-kernel-and-haproxy-instance-for-high-loads-1a2105ea553e ): $ ulimit -n 655360 Anything else you?d like to know? I completely agree with you regarding the Port locks. But when 1 collision occurs, it tooks 72?690'401usec. That?s my concern :-/ Can these Port locks be avoided? Is there any undocumented feature I can try? I?m open to test any idea and/or change my design architecture if needed. Thanks in advance. /Frank Fri 3 jan 2020 at 10:21, D?niel Szoboszlay wrote : > Hi Frank, > > I think some context would help us to better understand your problem. For > example what kind of problems do these lock conflicts cause in your system? > Are there some Erlang processes that got stuck for several seconds? What > are they trying to do at that time? Or is it only that the throughput you > experience stays below your expectations? > > The lock stats in the gists don't seem that wrong to me. I don't have much > experience with lock counters and can't figure out from the gists what do > these ports are (the image files? tcp connections?) and how they are used, > but my guess is they are the tcp connections. Each port lock is tried 4 or > 5 times and there's only 1 (albeit often very long) collision. This is how > I'd expect a web server to handle a tcp connection: do one read, one write, > close it - a handful of operations only. And if you have an unresponsive > client or bad network, one operation may easily take 6-7 seconds, blocking > the next one. So just a guess, but is it possible you attempt to use the > same tcp socket from two different processes? > > Cheers, > Daniel > > On Fri, 3 Jan 2020 at 00:40, Frank Muller > wrote: > >> The more load we have, the more locks contention we get: >> >> https://gist.github.com/frankmullerl/7fb9470e22869312d97011c0faf0046b >> >> /Frank >> >> >> Hi Mikael >>> >>> Thanks for pointing out prim_inet. To my knowledge, it?s undocumented I >>> can be changed by the OTP team. That?s why I?ve avoided it at the first >>> place. >>> >>> By the way, you probably mean prim_inet:sendfile/4 not 8, correct? >>> >>> I made a quick the change to my app and found that the throughput is a >>> little bit better (3% faster). >>> >>> But these port locks are still there :-/ >>> Any other ideas? >>> >>> /Frank >>> >>> On Thu, Jan 2, 2020 at 5:38 PM Frank Muller >>> wrote: >>> >>>> > >>>> > Thanks to @Peti G?m?ri, I was able to identify these Port locks: >>>> > https://gist.github.com/frankmullerl/008174c6594ca27584ac7f4e6724bee5 >>>> > >>>> > Some of them are taking up to 6.7sec (6707846 usec) :-/ >>>> > >>>> > My application is serving static images by calling file:sendfile/2 ( >>>> https://erlang.org/doc/man/file.html#sendfile-2). >>>> > >>>> > Can someone please explain how I can avoid these locks or at least >>>> make their impact lesser? >>>> >>>> Using the file module has been known to cause synchronization >>>> overheads. Often we (Klarna) use prim_file instead, >>>> but it has sendfile/8 not /2. Anyway, that may be an avenue worth >>>> investigating. >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex@REDACTED Fri Jan 3 23:26:04 2020 From: alex@REDACTED (alex@REDACTED) Date: Fri, 3 Jan 2020 17:26:04 -0500 Subject: build erlang otp 22.2 but can't used observer In-Reply-To: References: Message-ID: Something to point out is that wxWidgets (wx) version 3.1.3 is a development version and in overall you want to stick with stable version 3.0.4.? Don't remember if Erlang has an issue with 3.1.3, but I know I've run into problems with other software that depends on wx.? Once you compile wx and install it as root (if you didn't use a --prefix location, it should install under /usr/local).? Thus, wx-config should default to /usr/local/bin.? Now, it's up to your system config to have those paths available.? You can run ldconfig from the console/terminal you're using for this process or simply reboot to make sure the libraries are made available.? Note again that you might need to use /etc/ld.so.conf to make /usr/local/{lib, lib64} available for dynamic linking.? From there on, just configure the Erlang as stated.? Note that the github version of Erlang doesn't bring a configure file with it.? You need to run "otp_build autoconf" from its base directory first. Cheers, Alex On 1/2/20 5:04 AM, Rareman S wrote: > Hi, > > > here build?wxWidgets-3.1.3? successful? I give some output (full in > attached) and/or configure options below also i tried build simple > configure option still can't used wx on otp22.2. On solaris didn't > have ldconfig or ld.so.conf > Question > How to put/integrate new wx3.1.3 into otp22? (i just create new > symbolic link remove the old) > > REF > ./configure --with-opengl --with-gtk=3 --enable-stc --enable-webview > ?--enable-shared --enable-compat28 > ?wx-config --version > 3.1.3 > wx-config --list > > ? ? Default config is gtk3-unicode-3.1 > > ? Default config in /export/home/itmxadm/WX/wxWidgets-3.1.3 will be > used for output > > ? Alternate matches: > ? ? gtk2-ansi-3.1 > ? ? gtk2-unicode-3.1 > ?wx-config --libs > -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib -pthreads > -Wl,-rpath,/export/home/itmxadm/WX/wxWidgets-3.1.3/lib > -lwx_gtk3u_xrc-3.1 -lwx_gtk3u_html-3.1 -lwx_gtk3u_qa-3.1 > -lwx_gtk3u_core-3.1 -lwx_baseu_xml-3.1 -lwx_baseu_net-3.1 -lwx_baseu-3.1 > > /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o > richtextdll_richtextstyledlg.o ?-D__WXGTK__ ? ? ?-DWXBUILDING ? ? > ?-I./src/regex ?-DWXUSINGDLL -DWXMAKINGDLL_RICHTEXT -fPIC -DPIC -Wall > -Wundef -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual > -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=64 > -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 > -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS > -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 > -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 > -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 > -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include > -I/usr/include/harfbuzz -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem > /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT -O2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/freetype2 -I/usr/include/pango-1.0 > -I/usr/include/harfbuzz -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS > -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS > -I/usr/include/gtk-3.0/unix-print -I/usr/include/gtk-3.0 > -I/usr/include/atk-1.0 -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 > -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 > -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz > -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden > -fvisibility-inlines-hidden ./src/richtext/richtextstyledlg.cpp > /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o > richtextdll_richtextstyles.o ?-D__WXGTK__ ? ? ?-DWXBUILDING ? > ?-I./src/regex ?-DWXUSINGDLL -DWXMAKINGDLL_RICHTEXT -fPIC -DPIC -Wall > -Wundef -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual > -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=64 > -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 > -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS > -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 > -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 > -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 > -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include > -I/usr/include/harfbuzz -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem > /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT -O2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/freetype2 -I/usr/include/pango-1.0 > -I/usr/include/harfbuzz -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS > -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS > -I/usr/include/gtk-3.0/unix-print -I/usr/include/gtk-3.0 > -I/usr/include/atk-1.0 -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 > -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 > -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz > -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden > -fvisibility-inlines-hidden ./src/richtext/richtextstyles.cpp > /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o > richtextdll_richtextsymboldlg.o ?-D__WXGTK__ ? ? ?-DWXBUILDING ? ? > ?-I./src/regex ?-DWXUSINGDLL -DWXMAKINGDLL_RICHTEXT -fPIC -DPIC -Wall > -Wundef -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual > -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=64 > -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 > -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS > -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 > -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 > -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 > -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include > -I/usr/include/harfbuzz -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem > /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT -O2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/freetype2 -I/usr/include/pango-1.0 > -I/usr/include/harfbuzz -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS > -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS > -I/usr/include/gtk-3.0/unix-print -I/usr/include/gtk-3.0 > -I/usr/include/atk-1.0 -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 > -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 > -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz > -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden > -fvisibility-inlines-hidden ./src/richtext/richtextsymboldlg.cpp > /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o > richtextdll_richtextxml.o ?-D__WXGTK__ ? ? ?-DWXBUILDING > ?-I./src/regex ?-DWXUSINGDLL -DWXMAKINGDLL_RICHTEXT -fPIC -DPIC -Wall > -Wundef -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual > -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=64 > -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 > -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS > -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 > -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 > -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 > -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include > -I/usr/include/harfbuzz -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem > /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT -O2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/freetype2 -I/usr/include/pango-1.0 > -I/usr/include/harfbuzz -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS > -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS > -I/usr/include/gtk-3.0/unix-print -I/usr/include/gtk-3.0 > -I/usr/include/atk-1.0 -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 > -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 > -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz > -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden > -fvisibility-inlines-hidden ./src/richtext/richtextxml.cpp > /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o > richtextdll_xh_richtext.o ?-D__WXGTK__ ? ? ?-DWXBUILDING > ?-I./src/regex ?-DWXUSINGDLL -DWXMAKINGDLL_RICHTEXT -fPIC -DPIC -Wall > -Wundef -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual > -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=64 > -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 > -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS > -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 > -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 > -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 > -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include > -I/usr/include/harfbuzz -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem > /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT -O2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/freetype2 -I/usr/include/pango-1.0 > -I/usr/include/harfbuzz -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS > -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS > -I/usr/include/gtk-3.0/unix-print -I/usr/include/gtk-3.0 > -I/usr/include/atk-1.0 -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 > -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 > -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz > -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden > -fvisibility-inlines-hidden ./src/xrc/xh_richtext.cpp > g++ -shared -fPIC -o > /export/home/itmxadm/WX/wxWidgets-3.1.3/lib/libwx_gtk3u_richtext-3.1.so.3 > ?richtextdll_richtextbuffer.o richtextdll_richtextctrl.o > richtextdll_richtextformatdlg.o richtextdll_richtexthtml.o > richtextdll_richtextimagedlg.o richtextdll_richtextprint.o > richtextdll_richtextstyledlg.o richtextdll_richtextstyles.o > richtextdll_richtextsymboldlg.o richtextdll_richtextxml.o > richtextdll_xh_richtext.o > -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib > -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib > -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib > -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib > ?-L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib ? -h > libwx_gtk3u_richtext-3.1.so.3 ?-pthreads ? ? ? ? -lgtk-3 -lgdk-3 > -latk-1.0 -lgio-2.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo-gobject > -lpango-1.0 -lcairo -lgobject-2.0 -lgthread-2.0 -lpthread -lglib-2.0 > -lX11 -lXxf86vm -lSM -lgtk-3 -lgdk-3 -latk-1.0 -lgio-2.0 > -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo-gobject -lpango-1.0 -lcairo > -lgobject-2.0 -lglib-2.0 -lXtst -lpangoft2-1.0 -lpango-1.0 > -lfontconfig -lgobject-2.0 -lglib-2.0 -lfreetype -lpng -lz -ljpeg > -ltiff -llzma ?-lwxregexu-3.1 ?-pthreads ? ?-lz -lnsl -lsocket -llzma > -lm ?-lwx_gtk3u_html-3.1 -lwx_baseu_xml-3.1 -lwx_gtk3u_core-3.1 > -lwx_baseu-3.1 -lz -lnsl -lsocket -llzma -lm > (cd /export/home/itmxadm/WX/wxWidgets-3.1.3/lib/; rm -f > libwx_gtk3u_richtext-3.1.so ; ln > -s libwx_gtk3u_richtext-3.1.so.3 libwx_gtk3u_richtext-3.1.so > ) > /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o stcdll_stc.o > ?-D__WXGTK__ ? ? ?-DWXBUILDING ? ? ?-I./src/regex > ?-I./src/stc/scintilla/include -I./src/stc/scintilla/lexlib > -I./src/stc/scintilla/src -D__WX__ -DSCI_LEXER -DNO_CXX11_REGEX > -DLINK_LEXERS -DWXUSINGDLL -DWXMAKINGDLL_STC -fPIC -DPIC -Wall -Wundef > -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual > -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=64 > -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 > -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS > -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 > -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 > -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 > -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include > -I/usr/include/harfbuzz -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem > /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT -O2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/freetype2 -I/usr/include/pango-1.0 > -I/usr/include/harfbuzz -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS > -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS > -I/usr/include/gtk-3.0/unix-print -I/usr/include/gtk-3.0 > -I/usr/include/atk-1.0 -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 > -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 > -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz > -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden > -fvisibility-inlines-hidden ./src/stc/stc.cpp > /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o > stcdll_PlatWX.o ?-D__WXGTK__ ? ? ?-DWXBUILDING ?-I./src/regex > ?-I./src/stc/scintilla/include -I./src/stc/scintilla/lexlib > -I./src/stc/scintilla/src -D__WX__ -DSCI_LEXER -DNO_CXX11_REGEX > -DLINK_LEXERS -DWXUSINGDLL -DWXMAKINGDLL_STC -fPIC -DPIC -Wall -Wundef > -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual > -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=64 > -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 > -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS > -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 > -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 > -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 > -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include > -I/usr/include/harfbuzz -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem > /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT -O2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/freetype2 -I/usr/include/pango-1.0 > -I/usr/include/harfbuzz -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS > -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS > -I/usr/include/gtk-3.0/unix-print -I/usr/include/gtk-3.0 > -I/usr/include/atk-1.0 -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 > -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 > -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz > -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden > -fvisibility-inlines-hidden ./src/stc/PlatWX.cpp > /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o > stcdll_ScintillaWX.o ?-D__WXGTK__ ? ? ?-DWXBUILDING ?-I./src/regex > ?-I./src/stc/scintilla/include -I./src/stc/scintilla/lexlib > -I./src/stc/scintilla/src -D__WX__ -DSCI_LEXER -DNO_CXX11_REGEX > -DLINK_LEXERS -DWXUSINGDLL -DWXMAKINGDLL_STC -fPIC -DPIC -Wall -Wundef > -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual > -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=64 > -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 > -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS > -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 > -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 > -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 > -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include > -I/usr/include/harfbuzz -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem > /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT -O2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/freetype2 -I/usr/include/pango-1.0 > -I/usr/include/harfbuzz -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS > -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS > -I/usr/include/gtk-3.0/unix-print -I/usr/include/gtk-3.0 > -I/usr/include/atk-1.0 -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 > -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 > -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz > -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden > -fvisibility-inlines-hidden ./src/stc/ScintillaWX.cpp > g++ -shared -fPIC -o > /export/home/itmxadm/WX/wxWidgets-3.1.3/lib/libwx_gtk3u_stc-3.1.so.3 > ?stcdll_stc.o stcdll_PlatWX.o stcdll_ScintillaWX.o > ?-L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib > -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib > -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib > ?-L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib ? -h > libwx_gtk3u_stc-3.1.so.3 ?-pthreads ? ? ? ? -lgtk-3 -lgdk-3 -latk-1.0 > -lgio-2.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo-gobject > -lpango-1.0 -lcairo -lgobject-2.0 -lgthread-2.0 -lpthread -lglib-2.0 > -lX11 -lXxf86vm -lSM -lgtk-3 -lgdk-3 -latk-1.0 -lgio-2.0 > -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo-gobject -lpango-1.0 -lcairo > -lgobject-2.0 -lglib-2.0 -lXtst -lpangoft2-1.0 -lpango-1.0 > -lfontconfig -lgobject-2.0 -lglib-2.0 -lfreetype -lpng -lz -ljpeg > -ltiff -llzma ?-lwxregexu-3.1 ?-pthreads ? ?-lz -lnsl -lsocket -llzma > -lm ?-lwxscintilla-3.1 -lwx_gtk3u_core-3.1 -lwx_baseu-3.1 -lz -lnsl > -lsocket -llzma -lm > (cd /export/home/itmxadm/WX/wxWidgets-3.1.3/lib/; rm -f > libwx_gtk3u_stc-3.1.so ; ln -s > libwx_gtk3u_stc-3.1.so.3 libwx_gtk3u_stc-3.1.so > ) > /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o > gldll_glcmn.o ?-D__WXGTK__ ? ? ?-DWXBUILDING ?-I./src/regex > ?-DWXUSINGDLL -DWXMAKINGDLL_GL -fPIC -DPIC -Wall -Wundef > -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual > -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=64 > -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 > -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS > -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 > -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 > -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 > -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include > -I/usr/include/harfbuzz -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem > /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT -O2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/freetype2 -I/usr/include/pango-1.0 > -I/usr/include/harfbuzz -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS > -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS > -I/usr/include/gtk-3.0/unix-print -I/usr/include/gtk-3.0 > -I/usr/include/atk-1.0 -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 > -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 > -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz > -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden > -fvisibility-inlines-hidden ./src/common/glcmn.cpp > /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o > gldll_glx11.o ?-D__WXGTK__ ? ? ?-DWXBUILDING ?-I./src/regex > ?-DWXUSINGDLL -DWXMAKINGDLL_GL -fPIC -DPIC -Wall -Wundef > -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual > -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=64 > -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 > -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS > -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 > -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 > -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 > -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include > -I/usr/include/harfbuzz -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem > /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT -O2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/freetype2 -I/usr/include/pango-1.0 > -I/usr/include/harfbuzz -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS > -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS > -I/usr/include/gtk-3.0/unix-print -I/usr/include/gtk-3.0 > -I/usr/include/atk-1.0 -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 > -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 > -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz > -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden > -fvisibility-inlines-hidden ./src/unix/glx11.cpp > /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o > gldll_gtk_glcanvas.o ?-D__WXGTK__ ? ? ?-DWXBUILDING ?-I./src/regex > ?-DWXUSINGDLL -DWXMAKINGDLL_GL -fPIC -DPIC -Wall -Wundef > -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual > -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=64 > -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 > -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS > -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 > -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 > -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 > -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include > -I/usr/include/harfbuzz -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem > /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT -O2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/freetype2 -I/usr/include/pango-1.0 > -I/usr/include/harfbuzz -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS > -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS > -I/usr/include/gtk-3.0/unix-print -I/usr/include/gtk-3.0 > -I/usr/include/atk-1.0 -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 > -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 > -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz > -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden > -fvisibility-inlines-hidden ./src/gtk/glcanvas.cpp > g++ -shared -fPIC -o > /export/home/itmxadm/WX/wxWidgets-3.1.3/lib/libwx_gtk3u_gl-3.1.so.3 > ?gldll_glcmn.o gldll_glx11.o gldll_gtk_glcanvas.o > ?-L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib ? -h > libwx_gtk3u_gl-3.1.so.3 ?-pthreads ? ? ? ? -lgtk-3 -lgdk-3 -latk-1.0 > -lgio-2.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo-gobject > -lpango-1.0 -lcairo -lgobject-2.0 -lgthread-2.0 -lpthread -lglib-2.0 > -lX11 -lXxf86vm -lSM -lgtk-3 -lgdk-3 -latk-1.0 -lgio-2.0 > -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo-gobject -lpango-1.0 -lcairo > -lgobject-2.0 -lglib-2.0 -lXtst -lpangoft2-1.0 -lpango-1.0 > -lfontconfig -lgobject-2.0 -lglib-2.0 -lfreetype -lpng -lz -ljpeg > -ltiff -llzma ?-lwxregexu-3.1 ?-pthreads ? ?-lz -lnsl -lsocket -llzma > -lm ?-lwx_gtk3u_core-3.1 -lwx_baseu-3.1 ?-lGL -lGLU -lz -lnsl -lsocket > -llzma -lm > (cd /export/home/itmxadm/WX/wxWidgets-3.1.3/lib/; rm -f > libwx_gtk3u_gl-3.1.so ; ln -s > libwx_gtk3u_gl-3.1.so.3 libwx_gtk3u_gl-3.1.so > ) > (if test -f utils/wxrc/Makefile ; then cd utils/wxrc && /usr/bin/gmake > all ; fi) > gmake[1]: Entering directory > `/export/home/itmxadm/WX/wxWidgets-3.1.3/utils/wxrc' > /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o wxrc_wxrc.o > -D__WXGTK__ ? ? ?-I. -DWXUSINGDLL -DwxUSE_GUI=0 -Wall -Wundef > -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual > -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=64 > -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 > -I../../include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS > -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 > -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 > -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 > -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include > -I/usr/include/harfbuzz -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem > /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT -O2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/freetype2 -I/usr/include/pango-1.0 > -I/usr/include/harfbuzz -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS > -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS > -I/usr/include/gtk-3.0/unix-print -I/usr/include/gtk-3.0 > -I/usr/include/atk-1.0 -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 > -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 > -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz > -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden > -fvisibility-inlines-hidden ./wxrc.cpp > g++ -o wxrc wxrc_wxrc.o ?-L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib > ?-pthreads -lwx_baseu_xml-3.1 -lexpat -lwx_baseu-3.1 ? ? > -lwxregexu-3.1 ?-pthreads ? ?-lz -lnsl -lsocket -llzma -lm ?-lz -lnsl > -lsocket -llzma -lm > gmake[1]: Leaving directory > `/export/home/itmxadm/WX/wxWidgets-3.1.3/utils/wxrc' > > > > ???????? ?. 31 ?.?. 2019 ???? 04:33 alex@REDACTED > > > ????????: > > Oops, disregard the $wk, $stl and $st variable calls.? Sorry, but > I'm half awake, half sleep.? Actually "st" is for enabling shared > library, which is needed.? See below... > > On 12/30/19 4:24 PM, alex@REDACTED wrote: >> Yeah, looks like it cannot find the wx shared libraries. Verify >> the location of the wx files.? You might need to configure >> /etc/ld.so.conf to identify where they are located.? For >> reference, I personally compile wxWidgets from scratch with GTK3 >> and Mesa already installed with... >> >> export CFLAGS="-O3 -fPIC -march=native -pipe" >> export CXXFLAGS="$CFLAGS" >> >> CFLAGS CXXFLAGS ./configure \ >> --prefix=/usr \ >> ? --libdir=/usr/lib64 \ >> ? --sysconfdir=/etc \ >> ? --enable-mediactrl \ >> ? --with-opengl \ >> ? --enable-graphics_ctx \ >> ? --with-gtk=3 \ >> ? --enable-unicode \ >> ? --enable-compat28 \ >> ? --enable-plugins \ >> ? --enable-stc \ >> ? --enable-webview \ > ???? --enable-shared >> >> BTW, the configuration I use to compile Erlang is... >> >> CFLAGS ./configure \ >> ? --prefix=/usr \ >> ? --libdir=/usr/lib64 \ >> ? --without-odbc \ >> ? --without-megaco \ >> ? --enable-threads \ >> ? --enable-dirty-schedulers \ >> ? --enable-smp-support \ >> ? --enable-hipe >> >> ...follow by make and make install.? These are part of bigger >> scripts I use to make packages for my Linux distro, but this is >> practically it. >> >> Cheers, >> Alex >> >> On 12/30/19 11:48 AM, Mikael Pettersson wrote: >>> On Mon, Dec 30, 2019 at 4:48 PM Rareman S wrote: >>>> Hi, >>>> >>>> Here is my pre-build with erlang OTP22.2. >>> ... >>>> === Running configure in /export/home/itmxadm/otp-OTP-22.2/lib/wx === >>> ... >>>> checking if we can link wxwidgets programs... no >>>> configure: creating sparc-sun-solaris2.11/config.status >>>> config.status: creatingconfig.mk >>>> config.status: creating c_src/Makefile >>>> configure: WARNING: Can not find wx/stc/stc.h -Wall -fPIC -O -Wno-deprecated-declarations -fomit-frame-pointer -fno-strict-aliasing -D_GNU_SOURCE -D_THREAD_SAFE -D_REENTRANT -I/export/home/itmxadm/WX/wxWidgets-3.1.3/build_x11/lib/wx/include/x11univ-unicode-3.1 -I/export/home/itmxadm/WX/wxWidgets-3.1.3/include -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXUNIVERSAL__ -D__WXX11__ -pthreads -D_REENTRANT >>>> configure: WARNING: Can not link wx program are all developer packages installed? >>> ... >>>> wx : wxWidgets don't have gl support, wx will NOT be useable >>>> wxWidgets don't have wxStyledTextControl (stc.h), wx will NOT be useable >>>> Can not link the wx driver, wx will NOT be useable >>> ... >>>> ./configure CC=${IDE_CC} CXX=${IDE_CXX} CFLAGS="-O" CXXFLAGS=-g --enable-compat28 --prefix=/usr/local. Above config above after build successful can't used wx. >>> Given the wx-related warnings above, it's not surprising that wx >>> doesn't work for you. You'll need to inspect the config.log file for >>> lib/wx/ so see what the errors were, but off-hand it looks like an >>> incomplete wxWidgets installation. >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex@REDACTED Sat Jan 4 08:28:29 2020 From: alex@REDACTED (alex@REDACTED) Date: Sat, 4 Jan 2020 02:28:29 -0500 Subject: build erlang otp 22.2 but can't used observer In-Reply-To: <1adba854-4e7e-5419-f6b2-ad0405e0839e@xbasics.com> References: <1adba854-4e7e-5419-f6b2-ad0405e0839e@xbasics.com> Message-ID: <98a39b88748db1fc2c5f3a33e0249d17@smtp.hushmail.com> BTW, I should've mentioned also to try using a solution like kerl (https://github.com/kerl/kerl) or maybe asdf (https://github.com/asdf-vm/asdf).? That might be of help! Cheers, Alex On 1/3/20 5:26 PM, alex@REDACTED wrote: > Something to point out is that wxWidgets (wx) version 3.1.3 is a > development version and in overall you want to stick with stable > version 3.0.4.? Don't remember if Erlang has an issue with 3.1.3, but > I know I've run into problems with other software that depends on wx.? > Once you compile wx and install it as root (if you didn't use a > --prefix location, it should install under /usr/local).? Thus, > wx-config should default to /usr/local/bin.? Now, it's up to your > system config to have those paths available.? You can run ldconfig > from the console/terminal you're using for this process or simply > reboot to make sure the libraries are made available.? Note again that > you might need to use /etc/ld.so.conf to make /usr/local/{lib, lib64} > available for dynamic linking.? From there on, just configure the > Erlang as stated.? Note that the github version of Erlang doesn't > bring a configure file with it.? You need to run "otp_build autoconf" > from its base directory first. > > Cheers, > Alex > > On 1/2/20 5:04 AM, Rareman S wrote: >> Hi, >> >> >> here build?wxWidgets-3.1.3? successful? I give some output (full in >> attached) and/or configure options below also i tried build simple >> configure option still can't used wx on otp22.2. On solaris didn't >> have ldconfig or ld.so.conf >> Question >> How to put/integrate new wx3.1.3 into otp22? (i just create new >> symbolic link remove the old) >> >> REF >> ./configure --with-opengl --with-gtk=3 --enable-stc --enable-webview >> ?--enable-shared --enable-compat28 >> ?wx-config --version >> 3.1.3 >> wx-config --list >> >> ? ? Default config is gtk3-unicode-3.1 >> >> ? Default config in /export/home/itmxadm/WX/wxWidgets-3.1.3 will be >> used for output >> >> ? Alternate matches: >> ? ? gtk2-ansi-3.1 >> ? ? gtk2-unicode-3.1 >> ?wx-config --libs >> -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib -pthreads >> -Wl,-rpath,/export/home/itmxadm/WX/wxWidgets-3.1.3/lib >> -lwx_gtk3u_xrc-3.1 -lwx_gtk3u_html-3.1 -lwx_gtk3u_qa-3.1 >> -lwx_gtk3u_core-3.1 -lwx_baseu_xml-3.1 -lwx_baseu_net-3.1 -lwx_baseu-3.1 >> >> /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o >> richtextdll_richtextstyledlg.o ?-D__WXGTK__ ?-DWXBUILDING ? ? >> ?-I./src/regex ?-DWXUSINGDLL -DWXMAKINGDLL_RICHTEXT -fPIC -DPIC -Wall >> -Wundef -Wunused-parameter -Wno-ctor-dtor-privacy >> -Woverloaded-virtual -Wno-deprecated-declarations >> -D_FILE_OFFSET_BITS=64 >> -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 >> -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >> -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 >> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include >> -I/usr/include/harfbuzz -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem >> /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT >> -O2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/freetype2 -I/usr/include/pango-1.0 >> -I/usr/include/harfbuzz -I/usr/include/glib-2.0 >> -I/usr/lib/glib-2.0/include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS >> -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >> -I/usr/include/gtk-3.0/unix-print -I/usr/include/gtk-3.0 >> -I/usr/include/atk-1.0 -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 >> -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ >> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include >> -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 >> -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz >> -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden >> -fvisibility-inlines-hidden ./src/richtext/richtextstyledlg.cpp >> /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o >> richtextdll_richtextstyles.o ?-D__WXGTK__ ? ? ?-DWXBUILDING ? ? >> ?-I./src/regex ?-DWXUSINGDLL -DWXMAKINGDLL_RICHTEXT -fPIC -DPIC -Wall >> -Wundef -Wunused-parameter -Wno-ctor-dtor-privacy >> -Woverloaded-virtual -Wno-deprecated-declarations >> -D_FILE_OFFSET_BITS=64 >> -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 >> -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >> -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 >> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include >> -I/usr/include/harfbuzz -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem >> /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT >> -O2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/freetype2 -I/usr/include/pango-1.0 >> -I/usr/include/harfbuzz -I/usr/include/glib-2.0 >> -I/usr/lib/glib-2.0/include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS >> -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >> -I/usr/include/gtk-3.0/unix-print -I/usr/include/gtk-3.0 >> -I/usr/include/atk-1.0 -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 >> -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ >> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include >> -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 >> -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz >> -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden >> -fvisibility-inlines-hidden ./src/richtext/richtextstyles.cpp >> /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o >> richtextdll_richtextsymboldlg.o ?-D__WXGTK__ ?-DWXBUILDING ? ? >> ?-I./src/regex ?-DWXUSINGDLL -DWXMAKINGDLL_RICHTEXT -fPIC -DPIC -Wall >> -Wundef -Wunused-parameter -Wno-ctor-dtor-privacy >> -Woverloaded-virtual -Wno-deprecated-declarations >> -D_FILE_OFFSET_BITS=64 >> -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 >> -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >> -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 >> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include >> -I/usr/include/harfbuzz -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem >> /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT >> -O2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/freetype2 -I/usr/include/pango-1.0 >> -I/usr/include/harfbuzz -I/usr/include/glib-2.0 >> -I/usr/lib/glib-2.0/include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS >> -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >> -I/usr/include/gtk-3.0/unix-print -I/usr/include/gtk-3.0 >> -I/usr/include/atk-1.0 -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 >> -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ >> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include >> -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 >> -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz >> -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden >> -fvisibility-inlines-hidden ./src/richtext/richtextsymboldlg.cpp >> /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o >> richtextdll_richtextxml.o ?-D__WXGTK__ ? ? ?-DWXBUILDING >> ?-I./src/regex ?-DWXUSINGDLL -DWXMAKINGDLL_RICHTEXT -fPIC -DPIC -Wall >> -Wundef -Wunused-parameter -Wno-ctor-dtor-privacy >> -Woverloaded-virtual -Wno-deprecated-declarations >> -D_FILE_OFFSET_BITS=64 >> -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 >> -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >> -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 >> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include >> -I/usr/include/harfbuzz -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem >> /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT >> -O2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/freetype2 -I/usr/include/pango-1.0 >> -I/usr/include/harfbuzz -I/usr/include/glib-2.0 >> -I/usr/lib/glib-2.0/include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS >> -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >> -I/usr/include/gtk-3.0/unix-print -I/usr/include/gtk-3.0 >> -I/usr/include/atk-1.0 -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 >> -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ >> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include >> -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 >> -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz >> -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden >> -fvisibility-inlines-hidden ./src/richtext/richtextxml.cpp >> /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o >> richtextdll_xh_richtext.o ?-D__WXGTK__ ? ? ?-DWXBUILDING >> ?-I./src/regex ?-DWXUSINGDLL -DWXMAKINGDLL_RICHTEXT -fPIC -DPIC -Wall >> -Wundef -Wunused-parameter -Wno-ctor-dtor-privacy >> -Woverloaded-virtual -Wno-deprecated-declarations >> -D_FILE_OFFSET_BITS=64 >> -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 >> -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >> -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 >> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include >> -I/usr/include/harfbuzz -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem >> /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT >> -O2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/freetype2 -I/usr/include/pango-1.0 >> -I/usr/include/harfbuzz -I/usr/include/glib-2.0 >> -I/usr/lib/glib-2.0/include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS >> -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >> -I/usr/include/gtk-3.0/unix-print -I/usr/include/gtk-3.0 >> -I/usr/include/atk-1.0 -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 >> -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ >> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include >> -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 >> -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz >> -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden >> -fvisibility-inlines-hidden ./src/xrc/xh_richtext.cpp >> g++ -shared -fPIC -o >> /export/home/itmxadm/WX/wxWidgets-3.1.3/lib/libwx_gtk3u_richtext-3.1.so.3 >> ?richtextdll_richtextbuffer.o richtextdll_richtextctrl.o >> richtextdll_richtextformatdlg.o richtextdll_richtexthtml.o >> richtextdll_richtextimagedlg.o richtextdll_richtextprint.o >> richtextdll_richtextstyledlg.o richtextdll_richtextstyles.o >> richtextdll_richtextsymboldlg.o richtextdll_richtextxml.o >> richtextdll_xh_richtext.o >> -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib >> -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib >> -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib >> -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib >> ?-L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib ? -h >> libwx_gtk3u_richtext-3.1.so.3 ?-pthreads ? ? ? ? -lgtk-3 -lgdk-3 >> -latk-1.0 -lgio-2.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo-gobject >> -lpango-1.0 -lcairo -lgobject-2.0 -lgthread-2.0 -lpthread -lglib-2.0 >> -lX11 -lXxf86vm -lSM -lgtk-3 -lgdk-3 -latk-1.0 -lgio-2.0 >> -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo-gobject -lpango-1.0 -lcairo >> -lgobject-2.0 -lglib-2.0 -lXtst -lpangoft2-1.0 -lpango-1.0 >> -lfontconfig -lgobject-2.0 -lglib-2.0 -lfreetype -lpng -lz -ljpeg >> -ltiff -llzma ?-lwxregexu-3.1 ?-pthreads ? ?-lz -lnsl -lsocket -llzma >> -lm ?-lwx_gtk3u_html-3.1 -lwx_baseu_xml-3.1 -lwx_gtk3u_core-3.1 >> -lwx_baseu-3.1 -lz -lnsl -lsocket -llzma -lm >> (cd /export/home/itmxadm/WX/wxWidgets-3.1.3/lib/; rm -f >> libwx_gtk3u_richtext-3.1.so ; ln >> -s libwx_gtk3u_richtext-3.1.so.3 libwx_gtk3u_richtext-3.1.so >> ) >> /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o >> stcdll_stc.o ?-D__WXGTK__ ? ? ?-DWXBUILDING ?-I./src/regex >> ?-I./src/stc/scintilla/include -I./src/stc/scintilla/lexlib >> -I./src/stc/scintilla/src -D__WX__ -DSCI_LEXER -DNO_CXX11_REGEX >> -DLINK_LEXERS -DWXUSINGDLL -DWXMAKINGDLL_STC -fPIC -DPIC -Wall >> -Wundef -Wunused-parameter -Wno-ctor-dtor-privacy >> -Woverloaded-virtual -Wno-deprecated-declarations >> -D_FILE_OFFSET_BITS=64 >> -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 >> -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >> -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 >> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include >> -I/usr/include/harfbuzz -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem >> /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT >> -O2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/freetype2 -I/usr/include/pango-1.0 >> -I/usr/include/harfbuzz -I/usr/include/glib-2.0 >> -I/usr/lib/glib-2.0/include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS >> -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >> -I/usr/include/gtk-3.0/unix-print -I/usr/include/gtk-3.0 >> -I/usr/include/atk-1.0 -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 >> -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ >> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include >> -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 >> -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz >> -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden >> -fvisibility-inlines-hidden ./src/stc/stc.cpp >> /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o >> stcdll_PlatWX.o ?-D__WXGTK__ ? ? ?-DWXBUILDING ?-I./src/regex >> ?-I./src/stc/scintilla/include -I./src/stc/scintilla/lexlib >> -I./src/stc/scintilla/src -D__WX__ -DSCI_LEXER -DNO_CXX11_REGEX >> -DLINK_LEXERS -DWXUSINGDLL -DWXMAKINGDLL_STC -fPIC -DPIC -Wall >> -Wundef -Wunused-parameter -Wno-ctor-dtor-privacy >> -Woverloaded-virtual -Wno-deprecated-declarations >> -D_FILE_OFFSET_BITS=64 >> -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 >> -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >> -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 >> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include >> -I/usr/include/harfbuzz -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem >> /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT >> -O2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/freetype2 -I/usr/include/pango-1.0 >> -I/usr/include/harfbuzz -I/usr/include/glib-2.0 >> -I/usr/lib/glib-2.0/include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS >> -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >> -I/usr/include/gtk-3.0/unix-print -I/usr/include/gtk-3.0 >> -I/usr/include/atk-1.0 -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 >> -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ >> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include >> -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 >> -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz >> -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden >> -fvisibility-inlines-hidden ./src/stc/PlatWX.cpp >> /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o >> stcdll_ScintillaWX.o ?-D__WXGTK__ ? ? ?-DWXBUILDING ?-I./src/regex >> ?-I./src/stc/scintilla/include -I./src/stc/scintilla/lexlib >> -I./src/stc/scintilla/src -D__WX__ -DSCI_LEXER -DNO_CXX11_REGEX >> -DLINK_LEXERS -DWXUSINGDLL -DWXMAKINGDLL_STC -fPIC -DPIC -Wall >> -Wundef -Wunused-parameter -Wno-ctor-dtor-privacy >> -Woverloaded-virtual -Wno-deprecated-declarations >> -D_FILE_OFFSET_BITS=64 >> -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 >> -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >> -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 >> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include >> -I/usr/include/harfbuzz -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem >> /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT >> -O2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/freetype2 -I/usr/include/pango-1.0 >> -I/usr/include/harfbuzz -I/usr/include/glib-2.0 >> -I/usr/lib/glib-2.0/include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS >> -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >> -I/usr/include/gtk-3.0/unix-print -I/usr/include/gtk-3.0 >> -I/usr/include/atk-1.0 -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 >> -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ >> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include >> -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 >> -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz >> -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden >> -fvisibility-inlines-hidden ./src/stc/ScintillaWX.cpp >> g++ -shared -fPIC -o >> /export/home/itmxadm/WX/wxWidgets-3.1.3/lib/libwx_gtk3u_stc-3.1.so.3 >> ?stcdll_stc.o stcdll_PlatWX.o stcdll_ScintillaWX.o >> ?-L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib >> -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib >> -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib >> ?-L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib ? -h >> libwx_gtk3u_stc-3.1.so.3 ?-pthreads ? ? ? ? -lgtk-3 -lgdk-3 -latk-1.0 >> -lgio-2.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo-gobject >> -lpango-1.0 -lcairo -lgobject-2.0 -lgthread-2.0 -lpthread -lglib-2.0 >> -lX11 -lXxf86vm -lSM -lgtk-3 -lgdk-3 -latk-1.0 -lgio-2.0 >> -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo-gobject -lpango-1.0 -lcairo >> -lgobject-2.0 -lglib-2.0 -lXtst -lpangoft2-1.0 -lpango-1.0 >> -lfontconfig -lgobject-2.0 -lglib-2.0 -lfreetype -lpng -lz -ljpeg >> -ltiff -llzma ?-lwxregexu-3.1 ?-pthreads ? ?-lz -lnsl -lsocket -llzma >> -lm ?-lwxscintilla-3.1 -lwx_gtk3u_core-3.1 -lwx_baseu-3.1 -lz -lnsl >> -lsocket -llzma -lm >> (cd /export/home/itmxadm/WX/wxWidgets-3.1.3/lib/; rm -f >> libwx_gtk3u_stc-3.1.so ; ln -s >> libwx_gtk3u_stc-3.1.so.3 libwx_gtk3u_stc-3.1.so >> ) >> /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o >> gldll_glcmn.o ?-D__WXGTK__ ? ? ?-DWXBUILDING ?-I./src/regex >> ?-DWXUSINGDLL -DWXMAKINGDLL_GL -fPIC -DPIC -Wall -Wundef >> -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual >> -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=64 >> -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 >> -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >> -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 >> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include >> -I/usr/include/harfbuzz -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem >> /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT >> -O2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/freetype2 -I/usr/include/pango-1.0 >> -I/usr/include/harfbuzz -I/usr/include/glib-2.0 >> -I/usr/lib/glib-2.0/include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS >> -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >> -I/usr/include/gtk-3.0/unix-print -I/usr/include/gtk-3.0 >> -I/usr/include/atk-1.0 -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 >> -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ >> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include >> -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 >> -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz >> -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden >> -fvisibility-inlines-hidden ./src/common/glcmn.cpp >> /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o >> gldll_glx11.o ?-D__WXGTK__ ? ? ?-DWXBUILDING ?-I./src/regex >> ?-DWXUSINGDLL -DWXMAKINGDLL_GL -fPIC -DPIC -Wall -Wundef >> -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual >> -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=64 >> -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 >> -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >> -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 >> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include >> -I/usr/include/harfbuzz -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem >> /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT >> -O2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/freetype2 -I/usr/include/pango-1.0 >> -I/usr/include/harfbuzz -I/usr/include/glib-2.0 >> -I/usr/lib/glib-2.0/include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS >> -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >> -I/usr/include/gtk-3.0/unix-print -I/usr/include/gtk-3.0 >> -I/usr/include/atk-1.0 -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 >> -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ >> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include >> -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 >> -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz >> -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden >> -fvisibility-inlines-hidden ./src/unix/glx11.cpp >> /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o >> gldll_gtk_glcanvas.o ?-D__WXGTK__ ? ? ?-DWXBUILDING ?-I./src/regex >> ?-DWXUSINGDLL -DWXMAKINGDLL_GL -fPIC -DPIC -Wall -Wundef >> -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual >> -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=64 >> -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 >> -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >> -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 >> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include >> -I/usr/include/harfbuzz -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem >> /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT >> -O2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/freetype2 -I/usr/include/pango-1.0 >> -I/usr/include/harfbuzz -I/usr/include/glib-2.0 >> -I/usr/lib/glib-2.0/include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS >> -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >> -I/usr/include/gtk-3.0/unix-print -I/usr/include/gtk-3.0 >> -I/usr/include/atk-1.0 -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 >> -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ >> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include >> -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 >> -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz >> -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden >> -fvisibility-inlines-hidden ./src/gtk/glcanvas.cpp >> g++ -shared -fPIC -o >> /export/home/itmxadm/WX/wxWidgets-3.1.3/lib/libwx_gtk3u_gl-3.1.so.3 >> ?gldll_glcmn.o gldll_glx11.o gldll_gtk_glcanvas.o >> ?-L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib ? -h >> libwx_gtk3u_gl-3.1.so.3 ?-pthreads ? ? ? ? -lgtk-3 -lgdk-3 -latk-1.0 >> -lgio-2.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo-gobject >> -lpango-1.0 -lcairo -lgobject-2.0 -lgthread-2.0 -lpthread -lglib-2.0 >> -lX11 -lXxf86vm -lSM -lgtk-3 -lgdk-3 -latk-1.0 -lgio-2.0 >> -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo-gobject -lpango-1.0 -lcairo >> -lgobject-2.0 -lglib-2.0 -lXtst -lpangoft2-1.0 -lpango-1.0 >> -lfontconfig -lgobject-2.0 -lglib-2.0 -lfreetype -lpng -lz -ljpeg >> -ltiff -llzma ?-lwxregexu-3.1 ?-pthreads ? ?-lz -lnsl -lsocket -llzma >> -lm ?-lwx_gtk3u_core-3.1 -lwx_baseu-3.1 ?-lGL -lGLU -lz -lnsl >> -lsocket -llzma -lm >> (cd /export/home/itmxadm/WX/wxWidgets-3.1.3/lib/; rm -f >> libwx_gtk3u_gl-3.1.so ; ln -s >> libwx_gtk3u_gl-3.1.so.3 libwx_gtk3u_gl-3.1.so >> ) >> (if test -f utils/wxrc/Makefile ; then cd utils/wxrc && >> /usr/bin/gmake all ; fi) >> gmake[1]: Entering directory >> `/export/home/itmxadm/WX/wxWidgets-3.1.3/utils/wxrc' >> /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o wxrc_wxrc.o >> -D__WXGTK__ ? ? ?-I. -DWXUSINGDLL -DwxUSE_GUI=0 -Wall -Wundef >> -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual >> -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=64 >> -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 >> -I../../include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >> -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 >> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include >> -I/usr/include/harfbuzz -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem >> /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT >> -O2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/freetype2 -I/usr/include/pango-1.0 >> -I/usr/include/harfbuzz -I/usr/include/glib-2.0 >> -I/usr/lib/glib-2.0/include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS >> -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >> -I/usr/include/gtk-3.0/unix-print -I/usr/include/gtk-3.0 >> -I/usr/include/atk-1.0 -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 >> -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ >> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include >> -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 >> -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz >> -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden >> -fvisibility-inlines-hidden ./wxrc.cpp >> g++ -o wxrc wxrc_wxrc.o >> ?-L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib ?-pthreads ? >> -lwx_baseu_xml-3.1 -lexpat -lwx_baseu-3.1 -lwxregexu-3.1 ?-pthreads ? >> ?-lz -lnsl -lsocket -llzma -lm ?-lz -lnsl -lsocket -llzma -lm >> gmake[1]: Leaving directory >> `/export/home/itmxadm/WX/wxWidgets-3.1.3/utils/wxrc' >> >> >> >> ???????? ?. 31 ?.?. 2019 ???? 04:33 alex@REDACTED >> > > ????????: >> >> Oops, disregard the $wk, $stl and $st variable calls.? Sorry, but >> I'm half awake, half sleep.? Actually "st" is for enabling shared >> library, which is needed.? See below... >> >> On 12/30/19 4:24 PM, alex@REDACTED >> wrote: >>> Yeah, looks like it cannot find the wx shared libraries. Verify >>> the location of the wx files.? You might need to configure >>> /etc/ld.so.conf to identify where they are located.? For >>> reference, I personally compile wxWidgets from scratch with GTK3 >>> and Mesa already installed with... >>> >>> export CFLAGS="-O3 -fPIC -march=native -pipe" >>> export CXXFLAGS="$CFLAGS" >>> >>> CFLAGS CXXFLAGS ./configure \ >>> --prefix=/usr \ >>> ? --libdir=/usr/lib64 \ >>> ? --sysconfdir=/etc \ >>> ? --enable-mediactrl \ >>> ? --with-opengl \ >>> ? --enable-graphics_ctx \ >>> ? --with-gtk=3 \ >>> ? --enable-unicode \ >>> ? --enable-compat28 \ >>> ? --enable-plugins \ >>> ? --enable-stc \ >>> ? --enable-webview \ >> ???? --enable-shared >>> >>> BTW, the configuration I use to compile Erlang is... >>> >>> CFLAGS ./configure \ >>> ? --prefix=/usr \ >>> ? --libdir=/usr/lib64 \ >>> ? --without-odbc \ >>> ? --without-megaco \ >>> ? --enable-threads \ >>> ? --enable-dirty-schedulers \ >>> ? --enable-smp-support \ >>> ? --enable-hipe >>> >>> ...follow by make and make install.? These are part of bigger >>> scripts I use to make packages for my Linux distro, but this is >>> practically it. >>> >>> Cheers, >>> Alex >>> >>> On 12/30/19 11:48 AM, Mikael Pettersson wrote: >>>> On Mon, Dec 30, 2019 at 4:48 PM Rareman S wrote: >>>>> Hi, >>>>> >>>>> Here is my pre-build with erlang OTP22.2. >>>> ... >>>>> === Running configure in /export/home/itmxadm/otp-OTP-22.2/lib/wx === >>>> ... >>>>> checking if we can link wxwidgets programs... no >>>>> configure: creating sparc-sun-solaris2.11/config.status >>>>> config.status: creatingconfig.mk >>>>> config.status: creating c_src/Makefile >>>>> configure: WARNING: Can not find wx/stc/stc.h -Wall -fPIC -O -Wno-deprecated-declarations -fomit-frame-pointer -fno-strict-aliasing -D_GNU_SOURCE -D_THREAD_SAFE -D_REENTRANT -I/export/home/itmxadm/WX/wxWidgets-3.1.3/build_x11/lib/wx/include/x11univ-unicode-3.1 -I/export/home/itmxadm/WX/wxWidgets-3.1.3/include -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXUNIVERSAL__ -D__WXX11__ -pthreads -D_REENTRANT >>>>> configure: WARNING: Can not link wx program are all developer packages installed? >>>> ... >>>>> wx : wxWidgets don't have gl support, wx will NOT be useable >>>>> wxWidgets don't have wxStyledTextControl (stc.h), wx will NOT be useable >>>>> Can not link the wx driver, wx will NOT be useable >>>> ... >>>>> ./configure CC=${IDE_CC} CXX=${IDE_CXX} CFLAGS="-O" CXXFLAGS=-g --enable-compat28 --prefix=/usr/local. Above config above after build successful can't used wx. >>>> Given the wx-related warnings above, it's not surprising that wx >>>> doesn't work for you. You'll need to inspect the config.log file for >>>> lib/wx/ so see what the errors were, but off-hand it looks like an >>>> incomplete wxWidgets installation. >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Sat Jan 4 08:32:16 2020 From: max.lapshin@REDACTED (Max Lapshin) Date: Sat, 4 Jan 2020 10:32:16 +0300 Subject: Port locks with high time under LCNT In-Reply-To: References: Message-ID: I advise to try to refuse from sendfile and use pread/write Our Flussonic can serve 10-20 gigabits per second. We have removed all "optimisations" like mmap and so on and left with old plain read/write. -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank.muller.erl@REDACTED Sat Jan 4 08:59:27 2020 From: frank.muller.erl@REDACTED (Frank Muller) Date: Sat, 4 Jan 2020 08:59:27 +0100 Subject: Port locks with high time under LCNT In-Reply-To: References: Message-ID: Hi Max Those numbers are amazing. Can you please elaborate more? So, you read data from disk with file:pread/3 and send it out using gen_tcp:send/2. Am I right? /Frank Sat. 4 janv. 2020 at 08:32, Max Lapshin wrote : > I advise to try to refuse from sendfile and use pread/write > > Our Flussonic can serve 10-20 gigabits per second. We have removed all > "optimisations" like mmap and so on and left with > old plain read/write. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From v@REDACTED Sat Jan 4 09:17:22 2020 From: v@REDACTED (Valentin Micic) Date: Sat, 4 Jan 2020 10:17:22 +0200 Subject: Port locks with high time under LCNT In-Reply-To: References: Message-ID: <02509144-C95D-499D-A07B-2F435F4E5703@micic.co.za> Just my 2c (for what is) worth? There are some versions of Linux kernel that are known to cause performance problems. Recently, we had a situation where a particular OS kernel patch caused a serious performance degradation. We were lucky, as the same software ran on multiple machines with almost the same hardware configuration, thus we did not have to doubt Erlang, or our code to that matter. BTW: the worst performing machine was running at 30% capacity relative to the best performing machine. After a brief wild goose chase with a hardware vendor, they (the vendor) have established that the problem was not related to the Intel CPU (Speedstep Technology), as *we* initially suspected, but actual OS kernel version. When you become desperate enough, you could check your OS kernel version/patch level as well. V/ > On 03 Jan 2020, at 19:39, Frank Muller wrote: > > Hi Daniel > > Thanks for the feedback. Sorry for being unclear, but this thread discontinued when switched to 2020. I gave some context when I started it at: > http://erlang.org/pipermail/erlang-questions/2019-December/098910.html > > More context: > 1. I?m building a Hugo (https://gohugo.io/ ) like service in Erlang. > Actually, it?s much more simpler than Hugo. You ask for a file, and you get it (or not). > > 2. The design is simple. One Erlang process handles one incoming connection. > Thus, it?s not possible to mess up with TCP sockets here. Whether the file exists and gets delivered to the caller or not. > > 3. Average file size is ~150KB. Max file size: ~3MB > > 4. I?m using Erlang 22.2 on both Linux (prod system) and MacOS (dev). > > 5. The service is caping at 4'000 req/sec. > > 6. @Mikael Pettersson suggested to use prim_file:sendfile/8 which gaves us a boost of ~3% in throughput. > > 7. For now, I?m only using HTTP (no HTTPS). > > 8. Linux sysctl settings are good and tuned (https://medium.com/@pawilon/tuning-your-linux-kernel-and-haproxy-instance-for-high-loads-1a2105ea553e ): > $ ulimit -n > 655360 > > Anything else you?d like to know? > > I completely agree with you regarding the Port locks. But when 1 collision occurs, it tooks 72?690'401usec. > That?s my concern :-/ > > Can these Port locks be avoided? > Is there any undocumented feature I can try? > > I?m open to test any idea and/or change my design architecture if needed. > > Thanks in advance. > > /Frank > > > Fri 3 jan 2020 at 10:21, D?niel Szoboszlay > wrote : > Hi Frank, > > I think some context would help us to better understand your problem. For example what kind of problems do these lock conflicts cause in your system? Are there some Erlang processes that got stuck for several seconds? What are they trying to do at that time? Or is it only that the throughput you experience stays below your expectations? > > The lock stats in the gists don't seem that wrong to me. I don't have much experience with lock counters and can't figure out from the gists what do these ports are (the image files? tcp connections?) and how they are used, but my guess is they are the tcp connections. Each port lock is tried 4 or 5 times and there's only 1 (albeit often very long) collision. This is how I'd expect a web server to handle a tcp connection: do one read, one write, close it - a handful of operations only. And if you have an unresponsive client or bad network, one operation may easily take 6-7 seconds, blocking the next one. So just a guess, but is it possible you attempt to use the same tcp socket from two different processes? > > Cheers, > Daniel > > On Fri, 3 Jan 2020 at 00:40, Frank Muller > wrote: > The more load we have, the more locks contention we get: > > https://gist.github.com/frankmullerl/7fb9470e22869312d97011c0faf0046b > > /Frank > > > Hi Mikael > > Thanks for pointing out prim_inet. To my knowledge, it?s undocumented I can be changed by the OTP team. That?s why I?ve avoided it at the first place. > > By the way, you probably mean prim_inet:sendfile/4 not 8, correct? > > I made a quick the change to my app and found that the throughput is a little bit better (3% faster). > > But these port locks are still there :-/ > Any other ideas? > > /Frank > > On Thu, Jan 2, 2020 at 5:38 PM Frank Muller > wrote: > > > > Thanks to @Peti G?m?ri, I was able to identify these Port locks: > > https://gist.github.com/frankmullerl/008174c6594ca27584ac7f4e6724bee5 > > > > Some of them are taking up to 6.7sec (6707846 usec) :-/ > > > > My application is serving static images by calling file:sendfile/2 (https://erlang.org/doc/man/file.html#sendfile-2 ). > > > > Can someone please explain how I can avoid these locks or at least make their impact lesser? > > Using the file module has been known to cause synchronization > overheads. Often we (Klarna) use prim_file instead, > but it has sendfile/8 not /2. Anyway, that may be an avenue worth > investigating. -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Sat Jan 4 09:30:37 2020 From: max.lapshin@REDACTED (Max Lapshin) Date: Sat, 4 Jan 2020 11:30:37 +0300 Subject: Port locks with high time under LCNT In-Reply-To: References: Message-ID: Yes. And we repack from mp4 to mpegts on fly. We cannot do sendfile due to this requirement and it happened that we do not need to do it. So 10 gbps is an absolutely normal load for E5. But of course you need to be not green =) Disable all powersave. On Sat, Jan 4, 2020 at 10:59 AM Frank Muller wrote: > Hi Max > > Those numbers are amazing. Can you please elaborate more? > > So, you read data from disk with file:pread/3 and send it out using > gen_tcp:send/2. Am I right? > > /Frank > > Sat. 4 janv. 2020 at 08:32, Max Lapshin wrote : > >> I advise to try to refuse from sendfile and use pread/write >> >> Our Flussonic can serve 10-20 gigabits per second. We have removed all >> "optimisations" like mmap and so on and left with >> old plain read/write. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank.muller.erl@REDACTED Sat Jan 4 11:39:21 2020 From: frank.muller.erl@REDACTED (Frank Muller) Date: Sat, 4 Jan 2020 11:39:21 +0100 Subject: Port locks with high time under LCNT In-Reply-To: References: Message-ID: Gonna update my design, test and report back /Frank Sat. 4 janv. 2020 at 09:30, Max Lapshin wrote : > Yes. > And we repack from mp4 to mpegts on fly. We cannot do sendfile due to > this requirement and it happened that we do not need to do it. > > So 10 gbps is an absolutely normal load for E5. > > But of course you need to be not green =) Disable all powersave. > > On Sat, Jan 4, 2020 at 10:59 AM Frank Muller > wrote: > >> Hi Max >> >> Those numbers are amazing. Can you please elaborate more? >> >> So, you read data from disk with file:pread/3 and send it out using >> gen_tcp:send/2. Am I right? >> >> /Frank >> >> Sat. 4 janv. 2020 at 08:32, Max Lapshin wrote : >> >>> I advise to try to refuse from sendfile and use pread/write >>> >>> Our Flussonic can serve 10-20 gigabits per second. We have removed all >>> "optimisations" like mmap and so on and left with >>> old plain read/write. >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierrefenoll@REDACTED Sat Jan 4 17:16:08 2020 From: pierrefenoll@REDACTED (Pierre Fenoll) Date: Sat, 4 Jan 2020 17:16:08 +0100 Subject: Matching fun M:F/A In-Reply-To: References: Message-ID: > Admitting equality and by extension unification on function values is a dangerous game which you usually don't want to play. The reason is that equality often has to be tailored to the situation. Ah so this is the question I aimed to sidestep. This is not about anonymous funs nor un-exported functions. As D?niel expresses I think more clearly than I: > The proposal was not about (re)defining the semantics of these operations but making the language more consistent on where does it allow the use of them. Now I understand the use for this "cleaning up of some dark corner of the Erlang language" might not be obvious yet and it may bring more puzzling (to newcomers?) than expressiveness powers. I'm only asking: Is there a story behind this maybe unfortunate language result? How do you feel about being able to pattern match on fun M:F/A? Thanks & happy new years -- Pierre Fenoll On Fri, 3 Jan 2020 at 00:16, D?niel Szoboszlay wrote: > On Thu, 2 Jan 2020 at 13:41, Jesper Louis Andersen < > jesper.louis.andersen@REDACTED> wrote: > >> Admitting equality and by extension unification on function values is a >> dangerous game which you usually don't want to play. The reason is that >> equality often has to be tailored to the situation. >> >> > It may be a bit aside to the original topic, but I don't understand this > argument. Erlang already defines equality of function values, even pattern > matching works for them with the = operator. The proposal was not about > (re)defining the semantics of these operations but making the language more > consistent on where does it allow the use of them. > > Also, while it's true that function equality is undecidable, functions are > not the only data type where the language's built-in equality and pattern > matching are not tailored to the situation. In fact, it's quite common that > complex data structures allow expressing the same value in different, > unequal forms. For example both {[2],[1]} and {[],[1,2]} describe the same > queue value, yet they won't compare equal. I believe this is something > programmers are expected to understand and be aware of, and therefore they > shall also understand and be aware of the limitations of the built-in > function equality. > > Cheers, > Daniel > > PS: I played a bit with function equality and pattern matching while > writing my reply, and I personally found all but the last of these examples > intuitive (by the way, they all work with = in place of =:= too): > 1> F1 = fun lists:sort/1. > fun lists:sort/1 > 2> F2 = fun lists:sort/1. > fun lists:sort/1 > 3> F1 =:= F2. > true > 4> F = fun (X) -> F1([x | X]) end. > #Fun > 5> F =:= F. > true > 6> G = fun (X) -> F1([x | X]) end. > #Fun > 7> F =:= G. > true > 8> H = fun (X) -> F2([x | X]) end. > #Fun > 9> F =:= H. > false > > For anyone curious, F and H are not equal because we're in the shell, and > funs created in the shell will essentially take their source code in a free > variable, which for H is the following tuple: > {[{'F2',fun lists:sort/1}], > {eval,#Fun}, > {value,#Fun}, > [{clause,1, > [{var,1,'X'}], > [], > [{call,1,{var,1,'F2'},[{cons,1,{atom,1,x},{var,1,'X'}}]}]}]} > > Now it's obvious that while variables F1 and F2 are bound to the same > function value and would compare equal, shell funs using them would also > contain their variable names, which are different. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jose.valim@REDACTED Sat Jan 4 22:18:59 2020 From: jose.valim@REDACTED (=?UTF-8?Q?Jos=C3=A9_Valim?=) Date: Sat, 4 Jan 2020 22:18:59 +0100 Subject: Matching fun M:F/A In-Reply-To: References: Message-ID: > How do you feel about being able to pattern match on fun M:F/A? I personally don't agree with the argument of being "inconsistent". The pattern matching syntax has always been a subset of the language and with specific semantics. For example: #{1 => 2} is a literal map but #{1 => 2} literally in a pattern will also match #{1 => 2, 3 => 4}. I also consider the fact "fun M:F/A" is a literal to be an implementation detail rather than part of the language specification. Finally, I think pattern matching on fun M:F/A would lead to bad coupling (it couples to the function name). For example, imagine that I implement some function called "my_module:my_fun/1" which has some specific behaviour on "fun lists:keysearch/3". At first, a user of my API is calling it as expected: my_module:my_fun(fun lists:keysearch/3, List). And imagine elsewhere the user has to use the same function, but the indexes are zero-based, so they have to wrap it like this: my_module:my_fun(fun(Key, N, AList) -> lists:keysearch(Key, N + 1, AList) end, List). Those two functions will now behave in different ways, which would be extremely confusing. Sure, you can achieve this by doing the manual comparison with == (as with everything else) but I don't think we should be further encouraging this behaviour. I personally don't remember ever needing to compare function references. -- Jos? Valim -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.harris@REDACTED Sun Jan 5 01:39:37 2020 From: robert.harris@REDACTED (Harris, Robert) Date: Sun, 5 Jan 2020 00:39:37 +0000 Subject: Obtain message content of Erlang messages in dtrace In-Reply-To: <498EF4E8-0C4E-4C3C-82C3-F509C6D16715@um.edu.mt> References: <498EF4E8-0C4E-4C3C-82C3-F509C6D16715@um.edu.mt> Message-ID: > On 16 Dec 2019, at 12:02, Duncan Paul Attard wrote: > > I was experimenting with Erlang and dtrace, and am interested to know whether the message content exchanged between two Erlang processes can be obtained. In particular, I am interested in the `message-send` and `message-receive` probes. TL;DR you can use DTrace but you'll have to modify the Erlang VM. DTrace was intended to provide observation at the very lowest level. In the user land case, a process is viewed as a collection of load objects whose symbol tables describe functions and global variables. DTrace is organised as a framework of "providers" that expose certain events --- locations in executable code or moments in time --- and its "pid" provider permits the instrumentation of functions at their entry and return and at any offset between. One may inspect a process's environment in terms of its registers and its address space; also exposed are integer arguments on function entry and a return value on exit, but these are simply special cases of register use. This abstraction is particularly well suited to simple C applications: tracing function arguments is trivial and often sufficient in its own right. With some work to find their locations, local variables are visible. If some quantity is a pointer then dereferencing it is reasonably straight-forward. Composite data types are fully supported and may be navigated with varying degrees of ease, depending on the DTrace implementation. For more complex programs, the pid provider alone falls short and your question provides a perfect example. It may happen that some significant event, e.g. the receipt of a message, does not correspond to a well known location such as the entry to or the return from a function. Instead, it might lie somewhere within a function at an unstable offset determined only at compilation. How may one describe the location of this event? Worse, DTrace will reveal only the contents of a register or a memory location. Suppose that we obtain the value of the variable used in the Erlang VM to identify a message; perhaps it is a pointer. To what does it point? Likely something unwieldy to the developer and opaque to the user. DTrace provides a solution in the form of a static tracing point, in essence a C macro with a stable name that is visible to DTrace. Thus the developer can associate a named probe with some logical event (e.g. message receipt) and expose useful diagnostic data (e.g. a textual representation of the message itself). Turning at last to your actual problem, the message-receive probe is used at line 242 here: https://github.com/erlang/otp/blob/4d0c23bd19f138e4fcfedd11283636e96d6bbc4f/erts/emulator/beam/msg_instrs.tab#L227 (Note that variables exposed by the probe are initialised only if the probe itself is enabled, which is determined by the earlier macro at 227.) Interestingly, the message itself isn't exposed, which is why you have been unable to trace it. However, I imagine it would be feasible to patch the VM to do what you want. You would need to render the message as a string into a buffer and expose that buffer's address; an existing example of this idiom is https://github.com/erlang/otp/blob/4d0c23bd19f138e4fcfedd11283636e96d6bbc4f/erts/emulator/beam/global.h#L1603 The name for such static DTrace probes is USDT; you can read more about it at https://docs.oracle.com/cd/E37838_01/html/E61035/gkycs.html#scrolltoc but there may be differences on your OS (e.g. see DTrace(1) on macos). Robert Confidentiality Notice | This email and any included attachments may be privileged, confidential and/or otherwise protected from disclosure. Access to this email by anyone other than the intended recipient is unauthorized. If you believe you have received this email in error, please contact the sender immediately and delete all copies. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From duncan.attard.01@REDACTED Sun Jan 5 12:20:36 2020 From: duncan.attard.01@REDACTED (Duncan Paul Attard) Date: Sun, 5 Jan 2020 12:20:36 +0100 Subject: Obtain message content of Erlang messages in dtrace In-Reply-To: References: <498EF4E8-0C4E-4C3C-82C3-F509C6D16715@um.edu.mt> Message-ID: <1B586FB8-A69F-4139-AA3C-09AD601F952C@um.edu.mt> Thanks a lot for your detailed answer! > On 05 Jan 2020, at 01:39, Harris, Robert wrote: > > > >> On 16 Dec 2019, at 12:02, Duncan Paul Attard wrote: >> >> I was experimenting with Erlang and dtrace, and am interested to know whether the message content exchanged between two Erlang processes can be obtained. In particular, I am interested in the `message-send` and `message-receive` probes. > > TL;DR you can use DTrace but you'll have to modify the Erlang VM. > > DTrace was intended to provide observation at the very lowest level. In > the user land case, a process is viewed as a collection of load objects > whose symbol tables describe functions and global variables. DTrace is > organised as a framework of "providers" that expose certain events --- > locations in executable code or moments in time --- and its "pid" > provider permits the instrumentation of functions at their entry and > return and at any offset between. One may inspect a process's > environment in terms of its registers and its address space; also > exposed are integer arguments on function entry and a return value on > exit, but these are simply special cases of register use. > > This abstraction is particularly well suited to simple C applications: > tracing function arguments is trivial and often sufficient in its own > right. With some work to find their locations, local variables are > visible. If some quantity is a pointer then dereferencing it is > reasonably straight-forward. Composite data types are fully supported > and may be navigated with varying degrees of ease, depending on the > DTrace implementation. > > For more complex programs, the pid provider alone falls short and your > question provides a perfect example. It may happen that some > significant event, e.g. the receipt of a message, does not correspond to > a well known location such as the entry to or the return from a > function. Instead, it might lie somewhere within a function at an > unstable offset determined only at compilation. How may one describe > the location of this event? Worse, DTrace will reveal only the contents > of a register or a memory location. Suppose that we obtain the value of > the variable used in the Erlang VM to identify a message; perhaps it is > a pointer. To what does it point? Likely something unwieldy to the > developer and opaque to the user. > > DTrace provides a solution in the form of a static tracing point, in > essence a C macro with a stable name that is visible to DTrace. Thus > the developer can associate a named probe with some logical event (e.g. > message receipt) and expose useful diagnostic data (e.g. a textual > representation of the message itself). > > Turning at last to your actual problem, the message-receive probe is > used at line 242 here: > > https://github.com/erlang/otp/blob/4d0c23bd19f138e4fcfedd11283636e96d6bbc4f/erts/emulator/beam/msg_instrs.tab#L227 > > (Note that variables exposed by the probe are initialised only if the > probe itself is enabled, which is determined by the earlier macro at > 227.) > > Interestingly, the message itself isn't exposed, which is why you have > been unable to trace it. However, I imagine it would be feasible to > patch the VM to do what you want. You would need to render the message > as a string into a buffer and expose that buffer's address; an existing > example of this idiom is > > https://github.com/erlang/otp/blob/4d0c23bd19f138e4fcfedd11283636e96d6bbc4f/erts/emulator/beam/global.h#L1603 > > The name for such static DTrace probes is USDT; you can read more about > it at > > https://docs.oracle.com/cd/E37838_01/html/E61035/gkycs.html#scrolltoc > > but there may be differences on your OS (e.g. see DTrace(1) on macos). > > Robert > Confidentiality Notice | This email and any included attachments may be privileged, confidential and/or otherwise protected from disclosure. Access to this email by anyone other than the intended recipient is unauthorized. If you believe you have received this email in error, please contact the sender immediately and delete all copies. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From raoknz@REDACTED Sun Jan 5 14:13:33 2020 From: raoknz@REDACTED (Richard O'Keefe) Date: Mon, 6 Jan 2020 02:13:33 +1300 Subject: Matching fun M:F/A In-Reply-To: References: Message-ID: I'm trying to think of a non-*accidental* semantics for fun patterns. fun _:_/n matches any function reference of arity n, which certainly has something to do with how we can call it. fun _:_/_ matches any function reference. I'm struggling to imagine plausible use cases for this. Do you have some examples? On Wed, 1 Jan 2020 at 05:13, Pierre Fenoll wrote: > > Hi, > > Since a few releases, the value fun M:F/A (provided M, F & A are bound) is a literal. It can be read with file:consult/1 as well as erlang:binary_to_term/1. > > Running OTP 22, funs can be compared: > > eq(F) -> > %% Compiles & works as expected. > F == fun lists:keysearch/3. > > However MFAs cannot be matched: > > %% syntax error before: 'fun' > fmatch(fun lists:keysearch/3) -> true; > fmatch(_) -> false. > > cmatch(F) -> > case F of > %% illegal pattern > fun lists:keysearch/3 -> true; > %% illegal guard expression > X when X == fun lists:keysearch/3 -> true; > > %% illegal pattern > fun lists:_/3 -> inte; > fun _:handle_cast/2 -> resting; > _ -> false > end. > > Is this intended? > > I believe it would be interesting to allow such patterns as well as for fun _:_/_. > This could help in optimization through specialization and probably would make for some new approaches. > Among all funs only fully qualified funs can be expressed this way so this behaviour could be a bit surprising to some but MFAs are already comparable today so I'd say we're already halfway there. > > Thoughts? > > PS: it seems one is no longer able to log into bugs.erlang.org with GitHub credentials as https://bugs.erlang.org/login.jsp?os_destination=%2Fdefault.jsp doesn't provide the option anymore. Is this normal? > From mononcqc@REDACTED Mon Jan 6 16:07:02 2020 From: mononcqc@REDACTED (Fred Hebert) Date: Mon, 6 Jan 2020 10:07:02 -0500 Subject: Matching fun M:F/A In-Reply-To: References: Message-ID: On Sun, Jan 5, 2020 at 8:13 AM Richard O'Keefe wrote: > I'm trying to think of a non-*accidental* semantics for fun patterns. > fun _:_/n matches any function reference of arity n, which certainly > has something to do with how we can call it. > fun _:_/_ matches any function reference. > I'm struggling to imagine plausible use cases for this. > Do you have some examples? > > The latter pattern is not different from the is_function/1 guard, but the only place I can think of to call it (aside from serialization or hashing) would be when passing it to apply/2, which accepts a fun and a list of arguments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fly@REDACTED Mon Jan 6 16:08:26 2020 From: fly@REDACTED (Fred Youhanaie) Date: Mon, 6 Jan 2020 18:38:26 +0330 Subject: Matching fun M:F/A In-Reply-To: References: Message-ID: On 04/01/2020 19:46, Pierre Fenoll wrote: > How do you feel about being able to pattern match on fun M:F/A? The language debate aside, you can pattern match today using erlang:fun_info_mfa/1 and tuple patterns. So, your fmatch/1 example can be rewritten as fmatch(F) when is_function(F) -> fmatch(fun_info_mfa(F)); fmatch({lists, search, 3}) -> true; fmatch(_) -> false. and the cmatch/1 example as: cmatch(F) -> case fun_info_mfa(F) of ... use {M,F,A} triples for the patterns clauses ... Cheers, Fred From lukas@REDACTED Tue Jan 7 09:22:12 2020 From: lukas@REDACTED (Lukas Larsson) Date: Tue, 7 Jan 2020 09:22:12 +0100 Subject: diff between release tar.gz files In-Reply-To: References: Message-ID: Hello! On Thu, Dec 12, 2019 at 4:11 AM Wes James wrote: > What is the difference between: > > OTP-22.2-bundle.tar.gz > > and > > Source code (tar.gz) (OTP-22.2.tar.gz) > The bundle contains the OTP source together with the corba applications ( https://github.com/erlang/corba). It is mostly used by our internal tools, but is also available for others if they want to know which corba versions are part of which OTP release. Lukas -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.schultz@REDACTED Tue Jan 7 10:01:12 2020 From: andreas.schultz@REDACTED (Andreas Schultz) Date: Tue, 7 Jan 2020 10:01:12 +0100 Subject: Use of spinlocks in Erlang Message-ID: Hi, There is an interesting discussion going on about the "correct" use of spinlocks in user space applications on Linux on the LKML. That discussion prompted me to check the OTP source on how locks are implemented. Some of the arguments of the LKML discussion would seem to apply to the spinlocks (and maybe event the mutexes) used in Erlangs ERTS as well. The main takeaway seem to be this quote from Linus: > I repeat: *do not use spinlocks in user space, unless you actually know what you're doing*. And be aware that the likelihood that you know what you are doing is basically nil. Could any of the Erlang gurus or ERTS developers comment on the use of home grown mutexes and spinlocks in Erlang in light of that discussion? Blog post that started it: https://probablydance.com/2019/12/30/measuring-mutexes-spinlocks-and-how-bad-the-linux-scheduler-really-is/ Linus's response: https://www.realworldtech.com/forum/?threadid=189711&curpostid=189723 Author's response: https://www.realworldtech.com/forum/?threadid=189711&curpostid=189747 Linus follow up: https://www.realworldtech.com/forum/?threadid=189711&curpostid=189755 Linus additional follow up: https://www.realworldtech.com/forum/?threadid=189711&curpostid=189759 Many thanks Andreas -- Andreas Schultz -------------- next part -------------- An HTML attachment was scrubbed... URL: From john@REDACTED Tue Jan 7 13:04:48 2020 From: john@REDACTED (John =?ISO-8859-1?Q?H=F6gberg?=) Date: Tue, 7 Jan 2020 13:04:48 +0100 Subject: Port locks with high time under LCNT In-Reply-To: References: Message-ID: What you're seeing is caused by how we're using the `sendfile(2)` system call. Like all other file operations it's impossible to make it non-blocking on Linux, and since it's used from the output callback in the inet driver it will block the scheduler until completion (while the port lock is held, hence its visibility with `lcnt`). Fixing this is non-trivial so we might force it to use the read/send fallback in a patch. /John On Sat, 2020-01-04 at 11:39 +0100, Frank Muller wrote: > Gonna update my design, test and report back > /Frank > Sat. 4 janv. 2020 at 09:30, Max Lapshin wrote > : > > Yes.And we repack from mp4 to mpegts on fly. We cannot do sendfile > > due to this requirement and it happened that we do not need to do > > it. > > > > So 10 gbps is an absolutely normal load for E5. > > > > But of course you need to be not green =) Disable all powersave. > > On Sat, Jan 4, 2020 at 10:59 AM Frank Muller < > > frank.muller.erl@REDACTED> wrote: > > > Hi Max > > > Those numbers are amazing. Can you please elaborate more? > > > So, you read data from disk with file:pread/3 and send it out > > > using gen_tcp:send/2. Am I right? > > > /Frank > > > Sat. 4 janv. 2020 at 08:32, Max Lapshin > > > wrote : > > > > I advise to try to refuse from sendfile and use pread/write > > > > Our Flussonic can serve 10-20 gigabits per second. We have > > > > removed all "optimisations" like mmap and so on and left with > > > > old plain read/write. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.eskilson@REDACTED Tue Jan 7 13:45:22 2020 From: jesper.eskilson@REDACTED (Jesper Eskilson) Date: Tue, 7 Jan 2020 13:45:22 +0100 Subject: Dialyzer: show success typing of a given function Message-ID: Hi, Often when I'm chasing down dialyzer errors, I want to see the success typing of a function. Is there a way to do that? /Jesper -- *Jesper Eskilson* Senior Software Engineer Kred Core +46-72-855-8421 Klarna Bank AB (publ) Sveav?gen 46, 111 34 Stockholm Tel: +46 8 120 120 00 <+46812012000> Reg no: 556737-0431 klarna.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukas@REDACTED Tue Jan 7 14:05:00 2020 From: lukas@REDACTED (Lukas Larsson) Date: Tue, 7 Jan 2020 14:05:00 +0100 Subject: Only install manual pages (install-docs) In-Reply-To: <36E9BFCC-AF93-4A95-8DE8-3FA020DF808D@meetlost.com> References: <36E9BFCC-AF93-4A95-8DE8-3FA020DF808D@meetlost.com> Message-ID: Hello, On Wed, Jan 1, 2020 at 10:55 AM by wrote: > I am wondering any existing method to constrain the ?install-docs? command > to only install/touch the manual pages? > As far as I am aware there is no way to do this. You can, however, speed-up the doc build process by making sure that there is no fop tool installed. That way it will not spend time to build the pdf docs, but it will still build the html docs. Lukas -------------- next part -------------- An HTML attachment was scrubbed... URL: From elbrujohalcon@REDACTED Tue Jan 7 14:20:43 2020 From: elbrujohalcon@REDACTED (Fernando Benavides) Date: Tue, 7 Jan 2020 10:20:43 -0300 Subject: Dialyzer: show success typing of a given function In-Reply-To: References: Message-ID: You can use TypER for that, IIRC. Just remove your specs and run typer on your code, like you would run dialyzer. http://erlang.org/doc/man/typer.html On Tue, Jan 7, 2020 at 9:46 AM Jesper Eskilson wrote: > Hi, > > Often when I'm chasing down dialyzer errors, I want to see the success > typing of a function. Is there a way to do that? > > /Jesper > -- > > *Jesper Eskilson* > Senior Software Engineer > Kred Core > +46-72-855-8421 > > Klarna Bank AB (publ) > Sveav?gen 46, 111 34 Stockholm > Tel: +46 8 120 120 00 <+46812012000> > Reg no: 556737-0431 > klarna.com > > -- Brujo Benavides about.me/elbrujohalcon -------------- next part -------------- An HTML attachment was scrubbed... URL: From by@REDACTED Tue Jan 7 15:34:23 2020 From: by@REDACTED (by) Date: Tue, 7 Jan 2020 22:34:23 +0800 Subject: Only install manual pages (install-docs) In-Reply-To: References: <36E9BFCC-AF93-4A95-8DE8-3FA020DF808D@meetlost.com> Message-ID: Hello, Yes, after I found that fop is not a must have tool for building Erlang, I removed it from my dev machine (In most circumstances, I need manual pages only). If I am not the minority, this might be helpful if we implement this feature (I think we can call it install-mans). I can imagine the use case: build Erlang + manual pages, then deploy the package to the server. I am not sure, maybe a quick manual pages reading on remote console would be a common use case in production server? Yao > ? 2020?1?7??21:05?Lukas Larsson ??? > > Hello, > > On Wed, Jan 1, 2020 at 10:55 AM by > wrote: > I am wondering any existing method to constrain the ?install-docs? command to only install/touch the manual pages? > > As far as I am aware there is no way to do this. You can, however, speed-up the doc build process by making sure that there is no fop tool installed. That way it will not spend time to build the pdf docs, but it will still build the html docs. > > Lukas -------------- next part -------------- An HTML attachment was scrubbed... URL: From comptekki@REDACTED Tue Jan 7 15:48:33 2020 From: comptekki@REDACTED (Wes James) Date: Tue, 7 Jan 2020 07:48:33 -0700 Subject: diff between release tar.gz files In-Reply-To: References: Message-ID: OK. Thanks for the info! Wes On Tue, Jan 7, 2020 at 1:22 AM Lukas Larsson wrote: > Hello! > > On Thu, Dec 12, 2019 at 4:11 AM Wes James wrote: > >> What is the difference between: >> >> OTP-22.2-bundle.tar.gz >> >> and >> >> Source code (tar.gz) (OTP-22.2.tar.gz) >> > > The bundle contains the OTP source together with the corba applications ( > https://github.com/erlang/corba). It is mostly used by our internal > tools, but is also available for others if they want to know which corba > versions are part of which OTP release. > > Lukas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn@REDACTED Tue Jan 7 15:55:30 2020 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Tue, 7 Jan 2020 15:55:30 +0100 Subject: Matching fun M:F/A In-Reply-To: References: Message-ID: On Tue, Dec 31, 2019 at 5:12 PM Pierre Fenoll wrote: > Is this intended? Yes. There does not seem to be any compelling use cases, and the implementation is non-trivial. Also, while one minor inconsistency would be removed, another would be added in that one could match external funs and not local funs. /Bj?rn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From r.s.o.aliev@REDACTED Tue Jan 7 16:04:50 2020 From: r.s.o.aliev@REDACTED (=?UTF-8?B?0KAu0KEuINCQ0LvQuNC10LI=?=) Date: Tue, 7 Jan 2020 18:04:50 +0300 Subject: Distributing a buildable executable Message-ID: Hello list, What I have is: 1. Pure Erlang part, a simple gen_server; 2. Several C++ source files + cmake file, intended to be build into a standalone executable. I need to distribute both components in a single package, as my gen_server does open_port({spawn, my_executable}). Moreover, it uses an environmental variable to find the executable, so I need a way to set it too (I use the "QT5_EPORT_DIR=~/Path/to/executable rebar3 shell --apps my_app" command now, but it obviously needs to be generalized somehow). What is the standard way to distribute such a two-component Erlang package? Thank you. -- Regards, R.S. Aliev From frank.muller.erl@REDACTED Tue Jan 7 17:58:04 2020 From: frank.muller.erl@REDACTED (Frank Muller) Date: Tue, 7 Jan 2020 17:58:04 +0100 Subject: Port locks with high time under LCNT In-Reply-To: References: Message-ID: Hi John Thanks for clarifying the fact that sendfile call being synchronous (maybe this info should be be added to the doc). Switching from prim_file:sendfile to file:pread + gen_tcp:send (per @Max Lapshin suggestion) gave me a different landscape in term of locks: https://gist.github.com/frankmullerl/d9e8379b8250d84c5b170577c2ad3b89 Tail latency (+99%ile) is still high and the throughput more a less the same. How can I interpret these new LCNT info to improve things? Best /Frank Tue 7 janv. 2020 at 13:05, John H?gberg wrote : > What you're seeing is caused by how we're using the `sendfile(2)` system > call. Like all other file operations it's impossible to make it > non-blocking on Linux, and since it's used from the output callback in the > inet driver it will block the scheduler until completion (while the port > lock is held, hence its visibility with `lcnt`). Fixing this is non-trivial > so we might force it to use the read/send fallback in a patch. > > /John > > On Sat, 2020-01-04 at 11:39 +0100, Frank Muller wrote: > > Gonna update my design, test and report back > > /Frank > > Sat. 4 janv. 2020 at 09:30, Max Lapshin wrote : > > Yes. > And we repack from mp4 to mpegts on fly. We cannot do sendfile due to > this requirement and it happened that we do not need to do it. > > So 10 gbps is an absolutely normal load for E5. > > But of course you need to be not green =) Disable all powersave. > > On Sat, Jan 4, 2020 at 10:59 AM Frank Muller > wrote: > > Hi Max > > Those numbers are amazing. Can you please elaborate more? > > So, you read data from disk with file:pread/3 and send it out using > gen_tcp:send/2. Am I right? > > /Frank > > Sat. 4 janv. 2020 at 08:32, Max Lapshin wrote : > > I advise to try to refuse from sendfile and use pread/write > > Our Flussonic can serve 10-20 gigabits per second. We have removed all > "optimisations" like mmap and so on and left with > old plain read/write. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kenji@REDACTED Wed Jan 8 05:03:53 2020 From: kenji@REDACTED (Kenji Rikitake) Date: Wed, 8 Jan 2020 13:03:53 +0900 Subject: sfmt-erlang security notice 8-JAN-2020: regarding the Ambionics Security's PHP mt_seed() vulnerability Message-ID: The following is the security notice of sfmt-erlang, a random number module for Erlang based on SFMT, regarding the recently revealed attack against PHP mt_seed() vulnerability. I've already updated hex.pm/sfmt with a new package including the following security notice. -- Kenji Rikitake ## Security notice regarding the PHP mt_seed() vulnerability Ambionics Security published [an internal state retrieval algorithm of PHP `mt_rand()`](https://www.ambionics.io/blog/php-mt-rand-prediction) on 6-JAN-2020. sfmt-erlang uses the same seed-to-internal-state initialization algorithm at the function `init_gen_rand/1`. For reducting the possibility of the internal state revelation, use `init_by_list32/1` instead, better combined with `rand:uniform/1`. [Raimo Niskanen published a piece of code for this purpose]( http://erlang.org/pipermail/erlang-questions/2018-July/095875.html). *Note well that sfmt-erlang has no cryptographic security guarantee and MUST NOT be used for security purposes such as password generation.* Also: Version 0.13.0 and 0.13.1 Erlang and C code files are identical. Users have no need to upgrade. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.eskilson@REDACTED Wed Jan 8 10:47:36 2020 From: jesper.eskilson@REDACTED (Jesper Eskilson) Date: Wed, 8 Jan 2020 10:47:36 +0100 Subject: Dialyzer: show success typing of a given function In-Reply-To: References: Message-ID: Thanks! I would've liked an option to dialyzer to do this (so I don't need to replicate how I run dialyzer, which is sort of complicated). Also, typer seems to require source code, and I would like to be able to do this directly on the beams. /Jesper On Tue, Jan 7, 2020 at 2:21 PM Fernando Benavides wrote: > You can use TypER for that, IIRC. > Just remove your specs and run typer on your code, like you would run > dialyzer. > http://erlang.org/doc/man/typer.html > > On Tue, Jan 7, 2020 at 9:46 AM Jesper Eskilson > wrote: > >> Hi, >> >> Often when I'm chasing down dialyzer errors, I want to see the success >> typing of a function. Is there a way to do that? >> >> /Jesper >> -- >> >> *Jesper Eskilson* >> Senior Software Engineer >> Kred Core >> +46-72-855-8421 >> >> Klarna Bank AB (publ) >> Sveav?gen 46, 111 34 Stockholm >> Tel: +46 8 120 120 00 <+46812012000> >> Reg no: 556737-0431 >> klarna.com >> >> > > -- > > > Brujo Benavides > about.me/elbrujohalcon > > -- *Jesper Eskilson* Senior Software Engineer Kred Core +46-72-855-8421 Klarna Bank AB (publ) Sveav?gen 46, 111 34 Stockholm Tel: +46 8 120 120 00 <+46812012000> Reg no: 556737-0431 klarna.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimo+erlang-questions@REDACTED Wed Jan 8 11:19:18 2020 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Wed, 8 Jan 2020 11:19:18 +0100 Subject: sfmt-erlang security notice 8-JAN-2020: regarding the Ambionics Security's PHP mt_seed() vulnerability In-Reply-To: References: Message-ID: <20200108101918.GA92176@erix.ericsson.se> On Wed, Jan 08, 2020 at 01:03:53PM +0900, Kenji Rikitake wrote: > The following is the security notice of sfmt-erlang, a random number module > for Erlang based on SFMT, regarding the recently revealed attack against > PHP mt_seed() vulnerability. > I've already updated hex.pm/sfmt with a new package including the following > security notice. > -- Kenji Rikitake > > ## Security notice regarding the PHP mt_seed() vulnerability Great that you keep an eye on these kinds of matters, Kenji! :-) > > Ambionics Security published [an internal state retrieval algorithm of PHP > `mt_rand()`](https://www.ambionics.io/blog/php-mt-rand-prediction) on > 6-JAN-2020. sfmt-erlang uses the same seed-to-internal-state initialization > algorithm at the function `init_gen_rand/1`. > > For reducting the possibility of the internal state revelation, use > `init_by_list32/1` instead, better combined with `rand:uniform/1`. [Raimo > Niskanen published a piece of code for this purpose]( > http://erlang.org/pipermail/erlang-questions/2018-July/095875.html). I would just like to emphasize that using `rand:uniform/1` with any algorithm in the `rand` module only _reduces_ the possibility for internal state revelation. All the steps in that Ambionics Security paper, as far as I can tell, can, in theory, be done on any algorithm in the `rand` module, albeit with much more work. Not yet figured out work, to be added... "Breaking" a non-secure PRNG like a Mersenne Twister is really a moot point since you can not break what is not supposed to hold. The Ambionics Security paper shows code that incorrectly used a non-secure PRNG to generate a password and then demonstartes exactly how efficiently that can be exploited. So what they actually broke was that incorrect code. > > *Note well that sfmt-erlang has no cryptographic security guarantee and > MUST NOT be used for security purposes such as password generation.* _That_ is a very important point here! > > Also: Version 0.13.0 and 0.13.1 Erlang and C code files are identical. > Users have no need to upgrade. -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From dch@REDACTED Wed Jan 8 15:31:45 2020 From: dch@REDACTED (Dave Cottlehuber) Date: Wed, 08 Jan 2020 15:31:45 +0100 Subject: Distributing a buildable executable In-Reply-To: References: Message-ID: <749dacac-ce57-4e6e-8be1-e07d82e7bc9f@www.fastmail.com> On Tue, 7 Jan 2020, at 16:04, ?.?. ????? wrote: > Hello list, > > What I have is: > 1. Pure Erlang part, a simple gen_server; > 2. Several C++ source files + cmake file, intended to be build into a > standalone executable. > > I need to distribute both components in a single package, as my > gen_server does open_port({spawn, my_executable}). Moreover, it uses an > environmental variable to find the executable, so I need a way to set it > too (I use the "QT5_EPORT_DIR=~/Path/to/executable rebar3 shell --apps > my_app" command now, but it obviously needs to be generalized somehow). > > What is the standard way to distribute such a two-component Erlang package? > Thank you. > > > -- > Regards, > R.S. Aliev Hey RS, Distribute the binary in your application priv directory, & then however you deploy your app, you can check for & locate the binary at module load time: ```erl -module(flux_capacitor). -on_load(init/0). ... init() -> PrivDir = case code:priv_dir(?MODULE) of {error, _} -> %% ENOIDEA so make a wild guess EbinDir = filename:dirname(code:which(?MODULE)), AppPath = filename:dirname(EbinDir), filename:join(AppPath, "priv"); Path -> Path end, do_stuff(filename:join(PrivDir, "executable")). ``` Alternatively for a gen_server you might handle this in Module:init/1. see jiffy and associated rebar.config for how this all gets assembled. https://github.com/davisp/jiffy/blob/master/src/jiffy.erl#L181-L190 There's a bunch more useful stuff in Paul's nif-examples[1] repo, albeit targeted for NIFs obviously. If you need to compile the exe, enc[2] is the best rebar-ish extension I've used for this, but I don't know off-hand of any cmake-driven builds. [1]: https://github.com/davisp/nif-examples/tree/master/apps [2]: https://github.com/davisp/erlang-native-compiler A+ Dave From jesper.louis.andersen@REDACTED Wed Jan 8 15:48:05 2020 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Wed, 8 Jan 2020 15:48:05 +0100 Subject: sfmt-erlang security notice 8-JAN-2020: regarding the Ambionics Security's PHP mt_seed() vulnerability In-Reply-To: <20200108101918.GA92176@erix.ericsson.se> References: <20200108101918.GA92176@erix.ericsson.se> Message-ID: On Wed, Jan 8, 2020 at 11:19 AM Raimo Niskanen < raimo+erlang-questions@REDACTED> wrote: > On Wed, Jan 08, 2020 at 01:03:53PM +0900, Kenji Rikitake wrote: > > > > *Note well that sfmt-erlang has no cryptographic security guarantee and > > MUST NOT be used for security purposes such as password generation.* > > _That_ is a very important point here! > > This is the important part. CSPRNGs[0] are made to withstand these types of attacks. This is due to the fact they must withstand extension attacks, typically by rolling the internal state material forward in a ratchet so you can't go back to the earlier states. Otherwise, an attacker gaining access to the internal state would be able to roll the RNG state backwards. For example, consider we create a "CSPRNG" based on AES265 in CTR mode. Our internal state is {k, n} for a key k and a counter n and to produce the stream of randomness we compute AES_k(0), AES_k(1), AES_k(2), ... and so on. Now the problem is that if the attacker gains access to the pair {k, n} they can regenerate the whole sequence from the start up until n. [0] https://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kenji@REDACTED Thu Jan 9 05:41:38 2020 From: kenji@REDACTED (Kenji Rikitake) Date: Thu, 9 Jan 2020 13:41:38 +0900 Subject: sfmt-erlang security notice 8-JAN-2020: regarding the Ambionics Security's PHP mt_seed() vulnerability In-Reply-To: <20200108101918.GA92176@erix.ericsson.se> References: <20200108101918.GA92176@erix.ericsson.se> Message-ID: I've discovered it's not only PHP or sfmt-erlang, but any language or system which uses the reference initialization sequence (i.e. copying the init_gen_rand() of MT or SFMT distribution by the original authors) might be affected by this PRNG state disclosure. -- Kenji Rikitake On Wed, Jan 8, 2020 at 7:19 PM Raimo Niskanen < raimo+erlang-questions@REDACTED> wrote: > On Wed, Jan 08, 2020 at 01:03:53PM +0900, Kenji Rikitake wrote: > > The following is the security notice of sfmt-erlang, a random number > module > > for Erlang based on SFMT, regarding the recently revealed attack against > > PHP mt_seed() vulnerability. > > I've already updated hex.pm/sfmt with a new package including the > following > > security notice. > > -- Kenji Rikitake > > > > ## Security notice regarding the PHP mt_seed() vulnerability > > Great that you keep an eye on these kinds of matters, Kenji! :-) > > > > > Ambionics Security published [an internal state retrieval algorithm of > PHP > > `mt_rand()`](https://www.ambionics.io/blog/php-mt-rand-prediction) on > > 6-JAN-2020. sfmt-erlang uses the same seed-to-internal-state > initialization > > algorithm at the function `init_gen_rand/1`. > > > > For reducting the possibility of the internal state revelation, use > > `init_by_list32/1` instead, better combined with `rand:uniform/1`. [Raimo > > Niskanen published a piece of code for this purpose]( > > http://erlang.org/pipermail/erlang-questions/2018-July/095875.html). > > I would just like to emphasize that using `rand:uniform/1` with any > algorithm > in the `rand` module only _reduces_ the possibility for internal state > revelation. All the steps in that Ambionics Security paper, as far as I > can tell, can, in theory, be done on any algorithm in the `rand` module, > albeit with much more work. Not yet figured out work, to be added... > > "Breaking" a non-secure PRNG like a Mersenne Twister is really a moot point > since you can not break what is not supposed to hold. The Ambionics > Security paper shows code that incorrectly used a non-secure PRNG to > generate a password and then demonstartes exactly how efficiently that > can be exploited. So what they actually broke was that incorrect code. > > > > > *Note well that sfmt-erlang has no cryptographic security guarantee and > > MUST NOT be used for security purposes such as password generation.* > > _That_ is a very important point here! > > > > > > Also: Version 0.13.0 and 0.13.1 Erlang and C code files are identical. > > Users have no need to upgrade. > > -- > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.lindahl@REDACTED Thu Jan 9 11:40:11 2020 From: tobias.lindahl@REDACTED (Tobias Lindahl) Date: Thu, 9 Jan 2020 11:40:11 +0100 Subject: Dialyzer: show success typing of a given function In-Reply-To: References: Message-ID: Jesper, I think you might want to have a look at the function dialyzer_plt:pp_mod/1 I agree that there should be some command line option for this. I think I even had one at some point, but it seems to have got lost over time. Den ons 8 jan. 2020 kl 10:48 skrev Jesper Eskilson < jesper.eskilson@REDACTED>: > Thanks! I would've liked an option to dialyzer to do this (so I don't need > to replicate how I run dialyzer, which is sort of complicated). Also, typer > seems to require source code, and I would like to be able to do this > directly on the beams. > > /Jesper > > On Tue, Jan 7, 2020 at 2:21 PM Fernando Benavides > wrote: > >> You can use TypER for that, IIRC. >> Just remove your specs and run typer on your code, like you would run >> dialyzer. >> http://erlang.org/doc/man/typer.html >> >> On Tue, Jan 7, 2020 at 9:46 AM Jesper Eskilson < >> jesper.eskilson@REDACTED> wrote: >> >>> Hi, >>> >>> Often when I'm chasing down dialyzer errors, I want to see the success >>> typing of a function. Is there a way to do that? >>> >>> /Jesper >>> -- >>> >>> *Jesper Eskilson* >>> Senior Software Engineer >>> Kred Core >>> +46-72-855-8421 >>> >>> Klarna Bank AB (publ) >>> Sveav?gen 46, 111 34 Stockholm >>> Tel: +46 8 120 120 00 <+46812012000> >>> Reg no: 556737-0431 >>> klarna.com >>> >>> >> >> -- >> >> >> Brujo Benavides >> about.me/elbrujohalcon >> >> > > > -- > > *Jesper Eskilson* > Senior Software Engineer > Kred Core > +46-72-855-8421 > > Klarna Bank AB (publ) > Sveav?gen 46, 111 34 Stockholm > Tel: +46 8 120 120 00 <+46812012000> > Reg no: 556737-0431 > klarna.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.s.o.aliev@REDACTED Thu Jan 9 11:02:44 2020 From: r.s.o.aliev@REDACTED (=?UTF-8?B?0KAu0KEuINCQ0LvQuNC10LI=?=) Date: Thu, 9 Jan 2020 13:02:44 +0300 Subject: Distributing a buildable executable In-Reply-To: <749dacac-ce57-4e6e-8be1-e07d82e7bc9f@www.fastmail.com> References: <749dacac-ce57-4e6e-8be1-e07d82e7bc9f@www.fastmail.com> Message-ID: <305202ab-ee8b-40af-18af-35d10451f995@gmail.com> 08.01.2020 17:31, Dave Cottlehuber ?????: > On Tue, 7 Jan 2020, at 16:04, ?.?. ????? wrote: >> Hello list, >> >> What I have is: >> 1. Pure Erlang part, a simple gen_server; >> 2. Several C++ source files + cmake file, intended to be build into a >> standalone executable. >> >> I need to distribute both components in a single package, as my >> gen_server does open_port({spawn, my_executable}). Moreover, it uses an >> environmental variable to find the executable, so I need a way to set it >> too (I use the "QT5_EPORT_DIR=~/Path/to/executable rebar3 shell --apps >> my_app" command now, but it obviously needs to be generalized somehow). >> >> What is the standard way to distribute such a two-component Erlang package? >> Thank you. >> >> >> -- >> Regards, >> R.S. Aliev > > Hey RS, > > Distribute the binary in your application priv directory, & then however you > deploy your app, you can check for & locate the binary at module load time: > > ```erl > -module(flux_capacitor). > -on_load(init/0). > ... > init() -> > PrivDir = case code:priv_dir(?MODULE) of > {error, _} -> > %% ENOIDEA so make a wild guess > EbinDir = filename:dirname(code:which(?MODULE)), > AppPath = filename:dirname(EbinDir), > filename:join(AppPath, "priv"); > Path -> > Path > end, > do_stuff(filename:join(PrivDir, "executable")). > ``` > > Alternatively for a gen_server you might handle this in Module:init/1. > > see jiffy and associated rebar.config for how this all gets assembled. > > https://github.com/davisp/jiffy/blob/master/src/jiffy.erl#L181-L190 > > There's a bunch more useful stuff in Paul's nif-examples[1] repo, > albeit targeted for NIFs obviously. If you need to compile the exe, > enc[2] is the best rebar-ish extension I've used for this, but I don't > know off-hand of any cmake-driven builds. > > [1]: https://github.com/davisp/nif-examples/tree/master/apps > [2]: https://github.com/davisp/erlang-native-compiler > > A+ > Dave > Hey Dave, Thank you for the hints. I have no problem with NIFs and definitely wouldn't want to go that way here. The binary in question is intended to act as a server, without any knowledge of the client's particularities (thence erlang:port_command/2 etc). The idea i was toying in my head is to just run cmake && cp in the said gen_server's init. But that seems kinda unholy. So, i'll try enc. Thanks again. The source code is at https://bitbucket.org/r_s_o/epona, if you are interested. It is Qt5 GUI builder tool, somewhat similar to wxErlang, but simpler and much more declarative (see demo_gs.erl). Any suggestions are greatly appreciated. -- Regards, R.S. Aliev From jesper.eskilson@REDACTED Thu Jan 9 12:14:03 2020 From: jesper.eskilson@REDACTED (Jesper Eskilson) Date: Thu, 9 Jan 2020 12:14:03 +0100 Subject: Dialyzer: show success typing of a given function In-Reply-To: References: Message-ID: Thanks, I'll check it out. On Thu, Jan 9, 2020 at 11:40 AM Tobias Lindahl wrote: > Jesper, I think you might want to have a look at the function > dialyzer_plt:pp_mod/1 > > I agree that there should be some command line option for this. I think I > even had one at some point, but it seems to have got lost over time. > > Den ons 8 jan. 2020 kl 10:48 skrev Jesper Eskilson < > jesper.eskilson@REDACTED>: > >> Thanks! I would've liked an option to dialyzer to do this (so I don't >> need to replicate how I run dialyzer, which is sort of complicated). Also, >> typer seems to require source code, and I would like to be able to do this >> directly on the beams. >> >> /Jesper >> >> On Tue, Jan 7, 2020 at 2:21 PM Fernando Benavides < >> elbrujohalcon@REDACTED> wrote: >> >>> You can use TypER for that, IIRC. >>> Just remove your specs and run typer on your code, like you would run >>> dialyzer. >>> http://erlang.org/doc/man/typer.html >>> >>> On Tue, Jan 7, 2020 at 9:46 AM Jesper Eskilson < >>> jesper.eskilson@REDACTED> wrote: >>> >>>> Hi, >>>> >>>> Often when I'm chasing down dialyzer errors, I want to see the success >>>> typing of a function. Is there a way to do that? >>>> >>>> /Jesper >>>> -- >>>> >>>> *Jesper Eskilson* >>>> Senior Software Engineer >>>> Kred Core >>>> +46-72-855-8421 >>>> >>>> Klarna Bank AB (publ) >>>> Sveav?gen 46, 111 34 Stockholm >>>> Tel: +46 8 120 120 00 <+46812012000> >>>> Reg no: 556737-0431 >>>> klarna.com >>>> >>>> >>> >>> -- >>> >>> >>> Brujo Benavides >>> about.me/elbrujohalcon >>> >>> >> >> >> -- >> >> *Jesper Eskilson* >> Senior Software Engineer >> Kred Core >> +46-72-855-8421 >> >> Klarna Bank AB (publ) >> Sveav?gen 46, 111 34 Stockholm >> Tel: +46 8 120 120 00 <+46812012000> >> Reg no: 556737-0431 >> klarna.com >> >> -- *Jesper Eskilson* Senior Software Engineer Kred Core +46-72-855-8421 Klarna Bank AB (publ) Sveav?gen 46, 111 34 Stockholm Tel: +46 8 120 120 00 <+46812012000> Reg no: 556737-0431 klarna.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.eskilson@REDACTED Thu Jan 9 12:29:15 2020 From: jesper.eskilson@REDACTED (Jesper Eskilson) Date: Thu, 9 Jan 2020 12:29:15 +0100 Subject: Dialyzer: show success typing of a given function In-Reply-To: References: Message-ID: So, if I'm doing something like this: Errors = dialyzer:run(Options) how do I call dialyzer_plt:pp_mod(Mod), which seems to be looking inside an existing PLT file. I would like to show what dialyzer has discovered during the dialyzer:run/1 call. /Jesper On Thu, Jan 9, 2020 at 12:14 PM Jesper Eskilson wrote: > Thanks, I'll check it out. > > On Thu, Jan 9, 2020 at 11:40 AM Tobias Lindahl > wrote: > >> Jesper, I think you might want to have a look at the function >> dialyzer_plt:pp_mod/1 >> >> I agree that there should be some command line option for this. I think I >> even had one at some point, but it seems to have got lost over time. >> >> Den ons 8 jan. 2020 kl 10:48 skrev Jesper Eskilson < >> jesper.eskilson@REDACTED>: >> >>> Thanks! I would've liked an option to dialyzer to do this (so I don't >>> need to replicate how I run dialyzer, which is sort of complicated). Also, >>> typer seems to require source code, and I would like to be able to do this >>> directly on the beams. >>> >>> /Jesper >>> >>> On Tue, Jan 7, 2020 at 2:21 PM Fernando Benavides < >>> elbrujohalcon@REDACTED> wrote: >>> >>>> You can use TypER for that, IIRC. >>>> Just remove your specs and run typer on your code, like you would run >>>> dialyzer. >>>> http://erlang.org/doc/man/typer.html >>>> >>>> On Tue, Jan 7, 2020 at 9:46 AM Jesper Eskilson < >>>> jesper.eskilson@REDACTED> wrote: >>>> >>>>> Hi, >>>>> >>>>> Often when I'm chasing down dialyzer errors, I want to see the success >>>>> typing of a function. Is there a way to do that? >>>>> >>>>> /Jesper >>>>> -- >>>>> >>>>> *Jesper Eskilson* >>>>> Senior Software Engineer >>>>> Kred Core >>>>> +46-72-855-8421 >>>>> >>>>> Klarna Bank AB (publ) >>>>> Sveav?gen 46, 111 34 Stockholm >>>>> Tel: +46 8 120 120 00 <+46812012000> >>>>> Reg no: 556737-0431 >>>>> klarna.com >>>>> >>>>> >>>> >>>> -- >>>> >>>> >>>> Brujo Benavides >>>> about.me/elbrujohalcon >>>> >>>> >>> >>> >>> -- >>> >>> *Jesper Eskilson* >>> Senior Software Engineer >>> Kred Core >>> +46-72-855-8421 >>> >>> Klarna Bank AB (publ) >>> Sveav?gen 46, 111 34 Stockholm >>> Tel: +46 8 120 120 00 <+46812012000> >>> Reg no: 556737-0431 >>> klarna.com >>> >>> > > -- > > *Jesper Eskilson* > Senior Software Engineer > Kred Core > +46-72-855-8421 > > Klarna Bank AB (publ) > Sveav?gen 46, 111 34 Stockholm > Tel: +46 8 120 120 00 <+46812012000> > Reg no: 556737-0431 > klarna.com > > -- *Jesper Eskilson* Senior Software Engineer Kred Core +46-72-855-8421 Klarna Bank AB (publ) Sveav?gen 46, 111 34 Stockholm Tel: +46 8 120 120 00 <+46812012000> Reg no: 556737-0431 klarna.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From MChenini@REDACTED Thu Jan 9 14:07:53 2020 From: MChenini@REDACTED (Chenini, Mohamed) Date: Thu, 9 Jan 2020 13:07:53 +0000 Subject: UNSUBSCRIBE Message-ID: UNSUBSCRIBE Sensitivity: General/Internal ==================== This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From joagre@REDACTED Thu Jan 9 14:43:37 2020 From: joagre@REDACTED (Joakim G.) Date: Thu, 9 Jan 2020 14:43:37 +0100 Subject: esock_atom_user problem and Android builds Message-ID: <4c3e4f15-63a5-0cc8-313e-668d632e1068@gmail.com> Hi, I'm trying to cross compile BEAM for Android but I'm stuck on a compile error. It seems that 'esock_atom_user' is undeclared and I can not even find any decalartion of it on the emulator/erts code. Can anyone point me in the right direction? Cheers /Joakim jocke@REDACTED:~/src/erlang/otp_src_22.2$ make noboot make USE_PGO=false BOOT_PREFIX= build_erl_interface emulator libs local_setup ... make[4]: G?r till katalogen ?/home/jocke/src/erlang/otp_src_22.2/erts/emulator? ?MAKE?? ?opt make[5]: G?r till katalogen ?/home/jocke/src/erlang/otp_src_22.2/erts/emulator? ?GEN?? ?arm-unknown-linux-androideabi/gen_git_version.mk ?CC?? ?obj/arm-unknown-linux-androideabi/opt/smp/socket_util.o nifs/common/socket_util.c: In function 'esock_encode_packet_pkttype': nifs/common/socket_util.c:1495:21: error: 'esock_atom_user' undeclared (first use in this function) ???????? *ePktType = esock_atom_user; From tobias.lindahl@REDACTED Thu Jan 9 17:44:04 2020 From: tobias.lindahl@REDACTED (Tobias Lindahl) Date: Thu, 9 Jan 2020 17:44:04 +0100 Subject: Dialyzer: show success typing of a given function In-Reply-To: References: Message-ID: I used to build a plt for the system and then use the dialyzer_plt:pp_mod/1 on that one. It will probably only show the exported functions, though. Otherwise, you will need to modify dialyzer to be able to find it. At least originally, the plt was used to store all the intermediate results, and if you can get your hands on it before it is deleted you can look it up there. I remember that I removed the pruning of non-exported function to get all functions in the plt dump. Back then it was a one-liner. It appears that some things have changed in the 12 years since I left the code base, though, so I can't give you a better indication than this. Den tors 9 jan. 2020 kl 12:29 skrev Jesper Eskilson < jesper.eskilson@REDACTED>: > So, if I'm doing something like this: > > Errors = dialyzer:run(Options) > > how do I call dialyzer_plt:pp_mod(Mod), which seems to be looking inside > an existing PLT file. I would like to show what dialyzer has discovered > during the dialyzer:run/1 call. > > /Jesper > > On Thu, Jan 9, 2020 at 12:14 PM Jesper Eskilson < > jesper.eskilson@REDACTED> wrote: > >> Thanks, I'll check it out. >> >> On Thu, Jan 9, 2020 at 11:40 AM Tobias Lindahl >> wrote: >> >>> Jesper, I think you might want to have a look at the function >>> dialyzer_plt:pp_mod/1 >>> >>> I agree that there should be some command line option for this. I think >>> I even had one at some point, but it seems to have got lost over time. >>> >>> Den ons 8 jan. 2020 kl 10:48 skrev Jesper Eskilson < >>> jesper.eskilson@REDACTED>: >>> >>>> Thanks! I would've liked an option to dialyzer to do this (so I don't >>>> need to replicate how I run dialyzer, which is sort of complicated). Also, >>>> typer seems to require source code, and I would like to be able to do this >>>> directly on the beams. >>>> >>>> /Jesper >>>> >>>> On Tue, Jan 7, 2020 at 2:21 PM Fernando Benavides < >>>> elbrujohalcon@REDACTED> wrote: >>>> >>>>> You can use TypER for that, IIRC. >>>>> Just remove your specs and run typer on your code, like you would run >>>>> dialyzer. >>>>> http://erlang.org/doc/man/typer.html >>>>> >>>>> On Tue, Jan 7, 2020 at 9:46 AM Jesper Eskilson < >>>>> jesper.eskilson@REDACTED> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Often when I'm chasing down dialyzer errors, I want to see the >>>>>> success typing of a function. Is there a way to do that? >>>>>> >>>>>> /Jesper >>>>>> -- >>>>>> >>>>>> *Jesper Eskilson* >>>>>> Senior Software Engineer >>>>>> Kred Core >>>>>> +46-72-855-8421 >>>>>> >>>>>> Klarna Bank AB (publ) >>>>>> Sveav?gen 46, 111 34 Stockholm >>>>>> Tel: +46 8 120 120 00 <+46812012000> >>>>>> Reg no: 556737-0431 >>>>>> klarna.com >>>>>> >>>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> Brujo Benavides >>>>> about.me/elbrujohalcon >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> *Jesper Eskilson* >>>> Senior Software Engineer >>>> Kred Core >>>> +46-72-855-8421 >>>> >>>> Klarna Bank AB (publ) >>>> Sveav?gen 46, 111 34 Stockholm >>>> Tel: +46 8 120 120 00 <+46812012000> >>>> Reg no: 556737-0431 >>>> klarna.com >>>> >>>> >> >> -- >> >> *Jesper Eskilson* >> Senior Software Engineer >> Kred Core >> +46-72-855-8421 >> >> Klarna Bank AB (publ) >> Sveav?gen 46, 111 34 Stockholm >> Tel: +46 8 120 120 00 <+46812012000> >> Reg no: 556737-0431 >> klarna.com >> >> > > -- > > *Jesper Eskilson* > Senior Software Engineer > Kred Core > +46-72-855-8421 > > Klarna Bank AB (publ) > Sveav?gen 46, 111 34 Stockholm > Tel: +46 8 120 120 00 <+46812012000> > Reg no: 556737-0431 > klarna.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chalor99@REDACTED Fri Jan 10 05:18:12 2020 From: chalor99@REDACTED (Rareman S) Date: Fri, 10 Jan 2020 11:18:12 +0700 Subject: build erlang otp 22.2 but can't used observer In-Reply-To: <98a39b88748db1fc2c5f3a33e0249d17@smtp.hushmail.com> References: <1adba854-4e7e-5419-f6b2-ad0405e0839e@xbasics.com> <98a39b88748db1fc2c5f3a33e0249d17@smtp.hushmail.com> Message-ID: Hi Alex Thanks for help. Kerl/asdf need to connected to the internet right? I cannot direct connect to the internet for some reason. Current I did fixed some here below. checking for wx/stc/stc.h... yes checking if we can link wxwidgets programs... no Above if see previous mail "wx/stc/stc.h... no " i changed gcc from 4.8 to 4.5. how to link wxwidgets programs? **Ref ./configure CC=/usr/gcc/4.5/bin/gcc CXX=/usr/gcc/4.5/bin/g++ CFLAGS=-fPIC CXXFLAGS=-fPIC --with-opengl --enable-unicode --enable-graphics_ctx --enable-gnomeprint --disable-shared --disable-optimise ???????? ?. 4 ?.?. 2020 ???? 14:28 alex@REDACTED ????????: > BTW, I should've mentioned also to try using a solution like kerl ( > https://github.com/kerl/kerl) or maybe asdf ( > https://github.com/asdf-vm/asdf). That might be of help! > > Cheers, > Alex > > On 1/3/20 5:26 PM, alex@REDACTED wrote: > > Something to point out is that wxWidgets (wx) version 3.1.3 is a > development version and in overall you want to stick with stable version > 3.0.4. Don't remember if Erlang has an issue with 3.1.3, but I know I've > run into problems with other software that depends on wx. Once you compile > wx and install it as root (if you didn't use a --prefix location, it should > install under /usr/local). Thus, wx-config should default to > /usr/local/bin. Now, it's up to your system config to have those paths > available. You can run ldconfig from the console/terminal you're using for > this process or simply reboot to make sure the libraries are made > available. Note again that you might need to use /etc/ld.so.conf to make > /usr/local/{lib, lib64} available for dynamic linking. From there on, just > configure the Erlang as stated. Note that the github version of Erlang > doesn't bring a configure file with it. You need to run "otp_build > autoconf" from its base directory first. > > Cheers, > Alex > > On 1/2/20 5:04 AM, Rareman S wrote: > > Hi, > > > here build wxWidgets-3.1.3 successful I give some output (full in > attached) and/or configure options below also i tried build simple > configure option still can't used wx on otp22.2. On solaris didn't have > ldconfig or ld.so.conf > Question > How to put/integrate new wx3.1.3 into otp22? (i just create new symbolic > link remove the old) > > REF > ./configure --with-opengl --with-gtk=3 --enable-stc --enable-webview > --enable-shared --enable-compat28 > wx-config --version > 3.1.3 > wx-config --list > > Default config is gtk3-unicode-3.1 > > Default config in /export/home/itmxadm/WX/wxWidgets-3.1.3 will be used > for output > > Alternate matches: > gtk2-ansi-3.1 > gtk2-unicode-3.1 > wx-config --libs > -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib -pthreads > -Wl,-rpath,/export/home/itmxadm/WX/wxWidgets-3.1.3/lib -lwx_gtk3u_xrc-3.1 > -lwx_gtk3u_html-3.1 -lwx_gtk3u_qa-3.1 -lwx_gtk3u_core-3.1 > -lwx_baseu_xml-3.1 -lwx_baseu_net-3.1 -lwx_baseu-3.1 > > /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o > richtextdll_richtextstyledlg.o -D__WXGTK__ -DWXBUILDING > -I./src/regex -DWXUSINGDLL -DWXMAKINGDLL_RICHTEXT -fPIC -DPIC -Wall > -Wundef -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual > -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=64 > -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 > -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS > -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 > -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 > -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 > -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz > -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem > /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT -O2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/freetype2 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT > -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_PTHREADS > -D_POSIX_PTHREAD_SEMANTICS -I/usr/include/gtk-3.0/unix-print > -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 > -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 > -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz > -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden > -fvisibility-inlines-hidden ./src/richtext/richtextstyledlg.cpp > /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o > richtextdll_richtextstyles.o -D__WXGTK__ -DWXBUILDING > -I./src/regex -DWXUSINGDLL -DWXMAKINGDLL_RICHTEXT -fPIC -DPIC -Wall > -Wundef -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual > -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=64 > -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 > -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS > -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 > -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 > -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 > -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz > -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem > /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT -O2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/freetype2 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT > -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_PTHREADS > -D_POSIX_PTHREAD_SEMANTICS -I/usr/include/gtk-3.0/unix-print > -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 > -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 > -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz > -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden > -fvisibility-inlines-hidden ./src/richtext/richtextstyles.cpp > /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o > richtextdll_richtextsymboldlg.o -D__WXGTK__ -DWXBUILDING > -I./src/regex -DWXUSINGDLL -DWXMAKINGDLL_RICHTEXT -fPIC -DPIC -Wall > -Wundef -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual > -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=64 > -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 > -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS > -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 > -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 > -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 > -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz > -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem > /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT -O2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/freetype2 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT > -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_PTHREADS > -D_POSIX_PTHREAD_SEMANTICS -I/usr/include/gtk-3.0/unix-print > -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 > -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 > -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz > -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden > -fvisibility-inlines-hidden ./src/richtext/richtextsymboldlg.cpp > /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o > richtextdll_richtextxml.o -D__WXGTK__ -DWXBUILDING -I./src/regex > -DWXUSINGDLL -DWXMAKINGDLL_RICHTEXT -fPIC -DPIC -Wall -Wundef > -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual > -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=64 > -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 > -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS > -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 > -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 > -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 > -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz > -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem > /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT -O2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/freetype2 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT > -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_PTHREADS > -D_POSIX_PTHREAD_SEMANTICS -I/usr/include/gtk-3.0/unix-print > -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 > -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 > -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz > -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden > -fvisibility-inlines-hidden ./src/richtext/richtextxml.cpp > /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o > richtextdll_xh_richtext.o -D__WXGTK__ -DWXBUILDING -I./src/regex > -DWXUSINGDLL -DWXMAKINGDLL_RICHTEXT -fPIC -DPIC -Wall -Wundef > -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual > -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=64 > -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 > -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS > -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 > -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 > -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 > -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz > -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem > /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT -O2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/freetype2 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT > -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_PTHREADS > -D_POSIX_PTHREAD_SEMANTICS -I/usr/include/gtk-3.0/unix-print > -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 > -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 > -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz > -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden > -fvisibility-inlines-hidden ./src/xrc/xh_richtext.cpp > g++ -shared -fPIC -o > /export/home/itmxadm/WX/wxWidgets-3.1.3/lib/libwx_gtk3u_richtext-3.1.so.3 > richtextdll_richtextbuffer.o richtextdll_richtextctrl.o > richtextdll_richtextformatdlg.o richtextdll_richtexthtml.o > richtextdll_richtextimagedlg.o richtextdll_richtextprint.o > richtextdll_richtextstyledlg.o richtextdll_richtextstyles.o > richtextdll_richtextsymboldlg.o richtextdll_richtextxml.o > richtextdll_xh_richtext.o -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib > -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib > -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib > -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib > -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib -h > libwx_gtk3u_richtext-3.1.so.3 -pthreads -lgtk-3 -lgdk-3 -latk-1.0 > -lgio-2.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo-gobject -lpango-1.0 > -lcairo -lgobject-2.0 -lgthread-2.0 -lpthread -lglib-2.0 -lX11 -lXxf86vm > -lSM -lgtk-3 -lgdk-3 -latk-1.0 -lgio-2.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 > -lcairo-gobject -lpango-1.0 -lcairo -lgobject-2.0 -lglib-2.0 -lXtst > -lpangoft2-1.0 -lpango-1.0 -lfontconfig -lgobject-2.0 -lglib-2.0 -lfreetype > -lpng -lz -ljpeg -ltiff -llzma -lwxregexu-3.1 -pthreads -lz -lnsl > -lsocket -llzma -lm -lwx_gtk3u_html-3.1 -lwx_baseu_xml-3.1 > -lwx_gtk3u_core-3.1 -lwx_baseu-3.1 -lz -lnsl -lsocket -llzma -lm > (cd /export/home/itmxadm/WX/wxWidgets-3.1.3/lib/; rm -f > libwx_gtk3u_richtext-3.1.so; ln -s libwx_gtk3u_richtext-3.1.so.3 > libwx_gtk3u_richtext-3.1.so) > /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o stcdll_stc.o > -D__WXGTK__ -DWXBUILDING -I./src/regex > -I./src/stc/scintilla/include -I./src/stc/scintilla/lexlib > -I./src/stc/scintilla/src -D__WX__ -DSCI_LEXER -DNO_CXX11_REGEX > -DLINK_LEXERS -DWXUSINGDLL -DWXMAKINGDLL_STC -fPIC -DPIC -Wall -Wundef > -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual > -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=64 > -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 > -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS > -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 > -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 > -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 > -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz > -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem > /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT -O2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/freetype2 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT > -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_PTHREADS > -D_POSIX_PTHREAD_SEMANTICS -I/usr/include/gtk-3.0/unix-print > -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 > -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 > -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz > -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden > -fvisibility-inlines-hidden ./src/stc/stc.cpp > /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o stcdll_PlatWX.o > -D__WXGTK__ -DWXBUILDING -I./src/regex > -I./src/stc/scintilla/include -I./src/stc/scintilla/lexlib > -I./src/stc/scintilla/src -D__WX__ -DSCI_LEXER -DNO_CXX11_REGEX > -DLINK_LEXERS -DWXUSINGDLL -DWXMAKINGDLL_STC -fPIC -DPIC -Wall -Wundef > -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual > -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=64 > -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 > -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS > -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 > -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 > -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 > -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz > -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem > /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT -O2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/freetype2 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT > -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_PTHREADS > -D_POSIX_PTHREAD_SEMANTICS -I/usr/include/gtk-3.0/unix-print > -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 > -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 > -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz > -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden > -fvisibility-inlines-hidden ./src/stc/PlatWX.cpp > /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o > stcdll_ScintillaWX.o -D__WXGTK__ -DWXBUILDING -I./src/regex > -I./src/stc/scintilla/include -I./src/stc/scintilla/lexlib > -I./src/stc/scintilla/src -D__WX__ -DSCI_LEXER -DNO_CXX11_REGEX > -DLINK_LEXERS -DWXUSINGDLL -DWXMAKINGDLL_STC -fPIC -DPIC -Wall -Wundef > -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual > -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=64 > -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 > -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS > -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 > -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 > -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 > -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz > -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem > /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT -O2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/freetype2 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT > -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_PTHREADS > -D_POSIX_PTHREAD_SEMANTICS -I/usr/include/gtk-3.0/unix-print > -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 > -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 > -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz > -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden > -fvisibility-inlines-hidden ./src/stc/ScintillaWX.cpp > g++ -shared -fPIC -o > /export/home/itmxadm/WX/wxWidgets-3.1.3/lib/libwx_gtk3u_stc-3.1.so.3 > stcdll_stc.o stcdll_PlatWX.o stcdll_ScintillaWX.o > -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib > -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib > -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib > -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib -h > libwx_gtk3u_stc-3.1.so.3 -pthreads -lgtk-3 -lgdk-3 -latk-1.0 > -lgio-2.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo-gobject -lpango-1.0 > -lcairo -lgobject-2.0 -lgthread-2.0 -lpthread -lglib-2.0 -lX11 -lXxf86vm > -lSM -lgtk-3 -lgdk-3 -latk-1.0 -lgio-2.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 > -lcairo-gobject -lpango-1.0 -lcairo -lgobject-2.0 -lglib-2.0 -lXtst > -lpangoft2-1.0 -lpango-1.0 -lfontconfig -lgobject-2.0 -lglib-2.0 -lfreetype > -lpng -lz -ljpeg -ltiff -llzma -lwxregexu-3.1 -pthreads -lz -lnsl > -lsocket -llzma -lm -lwxscintilla-3.1 -lwx_gtk3u_core-3.1 -lwx_baseu-3.1 > -lz -lnsl -lsocket -llzma -lm > (cd /export/home/itmxadm/WX/wxWidgets-3.1.3/lib/; rm -f > libwx_gtk3u_stc-3.1.so; ln -s libwx_gtk3u_stc-3.1.so.3 > libwx_gtk3u_stc-3.1.so) > /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o gldll_glcmn.o > -D__WXGTK__ -DWXBUILDING -I./src/regex -DWXUSINGDLL > -DWXMAKINGDLL_GL -fPIC -DPIC -Wall -Wundef -Wunused-parameter > -Wno-ctor-dtor-privacy -Woverloaded-virtual -Wno-deprecated-declarations > -D_FILE_OFFSET_BITS=64 > -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 > -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS > -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 > -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 > -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 > -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz > -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem > /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT -O2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/freetype2 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT > -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_PTHREADS > -D_POSIX_PTHREAD_SEMANTICS -I/usr/include/gtk-3.0/unix-print > -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 > -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 > -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz > -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden > -fvisibility-inlines-hidden ./src/common/glcmn.cpp > /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o gldll_glx11.o > -D__WXGTK__ -DWXBUILDING -I./src/regex -DWXUSINGDLL > -DWXMAKINGDLL_GL -fPIC -DPIC -Wall -Wundef -Wunused-parameter > -Wno-ctor-dtor-privacy -Woverloaded-virtual -Wno-deprecated-declarations > -D_FILE_OFFSET_BITS=64 > -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 > -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS > -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 > -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 > -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 > -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz > -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem > /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT -O2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/freetype2 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT > -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_PTHREADS > -D_POSIX_PTHREAD_SEMANTICS -I/usr/include/gtk-3.0/unix-print > -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 > -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 > -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz > -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden > -fvisibility-inlines-hidden ./src/unix/glx11.cpp > /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o > gldll_gtk_glcanvas.o -D__WXGTK__ -DWXBUILDING -I./src/regex > -DWXUSINGDLL -DWXMAKINGDLL_GL -fPIC -DPIC -Wall -Wundef -Wunused-parameter > -Wno-ctor-dtor-privacy -Woverloaded-virtual -Wno-deprecated-declarations > -D_FILE_OFFSET_BITS=64 > -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 > -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS > -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 > -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 > -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 > -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz > -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem > /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT -O2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/freetype2 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT > -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_PTHREADS > -D_POSIX_PTHREAD_SEMANTICS -I/usr/include/gtk-3.0/unix-print > -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 > -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 > -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz > -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden > -fvisibility-inlines-hidden ./src/gtk/glcanvas.cpp > g++ -shared -fPIC -o > /export/home/itmxadm/WX/wxWidgets-3.1.3/lib/libwx_gtk3u_gl-3.1.so.3 > gldll_glcmn.o gldll_glx11.o gldll_gtk_glcanvas.o > -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib -h libwx_gtk3u_gl-3.1.so.3 > -pthreads -lgtk-3 -lgdk-3 -latk-1.0 -lgio-2.0 -lpangocairo-1.0 > -lgdk_pixbuf-2.0 -lcairo-gobject -lpango-1.0 -lcairo -lgobject-2.0 > -lgthread-2.0 -lpthread -lglib-2.0 -lX11 -lXxf86vm -lSM -lgtk-3 -lgdk-3 > -latk-1.0 -lgio-2.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo-gobject > -lpango-1.0 -lcairo -lgobject-2.0 -lglib-2.0 -lXtst -lpangoft2-1.0 > -lpango-1.0 -lfontconfig -lgobject-2.0 -lglib-2.0 -lfreetype -lpng -lz > -ljpeg -ltiff -llzma -lwxregexu-3.1 -pthreads -lz -lnsl -lsocket > -llzma -lm -lwx_gtk3u_core-3.1 -lwx_baseu-3.1 -lGL -lGLU -lz -lnsl > -lsocket -llzma -lm > (cd /export/home/itmxadm/WX/wxWidgets-3.1.3/lib/; rm -f > libwx_gtk3u_gl-3.1.so; ln -s libwx_gtk3u_gl-3.1.so.3 libwx_gtk3u_gl-3.1.so > ) > (if test -f utils/wxrc/Makefile ; then cd utils/wxrc && /usr/bin/gmake all > ; fi) > gmake[1]: Entering directory > `/export/home/itmxadm/WX/wxWidgets-3.1.3/utils/wxrc' > /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o wxrc_wxrc.o > -D__WXGTK__ -I. -DWXUSINGDLL -DwxUSE_GUI=0 -Wall -Wundef > -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual > -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=64 > -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 > -I../../include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS > -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 > -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 > -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 > -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz > -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem > /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT -O2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/freetype2 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT > -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_PTHREADS > -D_POSIX_PTHREAD_SEMANTICS -I/usr/include/gtk-3.0/unix-print > -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 > -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 > -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz > -I/usr/include/freetype2 > -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 > -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden > -fvisibility-inlines-hidden ./wxrc.cpp > g++ -o wxrc wxrc_wxrc.o -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib > -pthreads -lwx_baseu_xml-3.1 -lexpat -lwx_baseu-3.1 -lwxregexu-3.1 > -pthreads -lz -lnsl -lsocket -llzma -lm -lz -lnsl -lsocket -llzma -lm > gmake[1]: Leaving directory > `/export/home/itmxadm/WX/wxWidgets-3.1.3/utils/wxrc' > > > > ???????? ?. 31 ?.?. 2019 ???? 04:33 alex@REDACTED > ????????: > >> Oops, disregard the $wk, $stl and $st variable calls. Sorry, but I'm >> half awake, half sleep. Actually "st" is for enabling shared library, >> which is needed. See below... >> >> On 12/30/19 4:24 PM, alex@REDACTED wrote: >> >> Yeah, looks like it cannot find the wx shared libraries. Verify the >> location of the wx files. You might need to configure /etc/ld.so.conf to >> identify where they are located. For reference, I personally compile >> wxWidgets from scratch with GTK3 and Mesa already installed with... >> >> export CFLAGS="-O3 -fPIC -march=native -pipe" >> export CXXFLAGS="$CFLAGS" >> >> CFLAGS CXXFLAGS ./configure \ >> --prefix=/usr \ >> --libdir=/usr/lib64 \ >> --sysconfdir=/etc \ >> --enable-mediactrl \ >> --with-opengl \ >> --enable-graphics_ctx \ >> --with-gtk=3 \ >> --enable-unicode \ >> --enable-compat28 \ >> --enable-plugins \ >> --enable-stc \ >> --enable-webview \ >> >> --enable-shared >> >> >> BTW, the configuration I use to compile Erlang is... >> >> CFLAGS ./configure \ >> --prefix=/usr \ >> --libdir=/usr/lib64 \ >> --without-odbc \ >> --without-megaco \ >> --enable-threads \ >> --enable-dirty-schedulers \ >> --enable-smp-support \ >> --enable-hipe >> >> ...follow by make and make install. These are part of bigger scripts I >> use to make packages for my Linux distro, but this is practically it. >> >> Cheers, >> Alex >> >> On 12/30/19 11:48 AM, Mikael Pettersson wrote: >> >> On Mon, Dec 30, 2019 at 4:48 PM Rareman S wrote: >> >> Hi, >> >> Here is my pre-build with erlang OTP22.2. >> >> ... >> >> === Running configure in /export/home/itmxadm/otp-OTP-22.2/lib/wx === >> >> ... >> >> checking if we can link wxwidgets programs... no >> configure: creating sparc-sun-solaris2.11/config.status >> config.status: creating config.mk >> config.status: creating c_src/Makefile >> configure: WARNING: Can not find wx/stc/stc.h -Wall -fPIC -O -Wno-deprecated-declarations -fomit-frame-pointer -fno-strict-aliasing -D_GNU_SOURCE -D_THREAD_SAFE -D_REENTRANT -I/export/home/itmxadm/WX/wxWidgets-3.1.3/build_x11/lib/wx/include/x11univ-unicode-3.1 -I/export/home/itmxadm/WX/wxWidgets-3.1.3/include -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXUNIVERSAL__ -D__WXX11__ -pthreads -D_REENTRANT >> configure: WARNING: Can not link wx program are all developer packages installed? >> >> ... >> >> wx : wxWidgets don't have gl support, wx will NOT be useable >> wxWidgets don't have wxStyledTextControl (stc.h), wx will NOT be useable >> Can not link the wx driver, wx will NOT be useable >> >> ... >> >> ./configure CC=${IDE_CC} CXX=${IDE_CXX} CFLAGS="-O" CXXFLAGS=-g --enable-compat28 --prefix=/usr/local. Above config above after build successful can't used wx. >> >> Given the wx-related warnings above, it's not surprising that wx >> doesn't work for you. You'll need to inspect the config.log file for >> lib/wx/ so see what the errors were, but off-hand it looks like an >> incomplete wxWidgets installation. >> >> >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From otp@REDACTED Fri Jan 10 11:37:48 2020 From: otp@REDACTED (Erlang/OTP) Date: Fri, 10 Jan 2020 11:37:48 +0100 (CET) Subject: Patch Package OTP 22.1.8.1 Released Message-ID: <20200110103748.38CA925479E@hel.cslab.ericsson.net> Patch Package: OTP 22.1.8.1 Git Tag: OTP-22.1.8.1 Date: 2020-01-10 Trouble Report Id: OTP-16349, OTP-16360 Seq num: ERIERL-444, ERIERL-451 System: OTP Release: 22 Application: snmp-5.4.3.1 Predecessor: OTP 22.1.8 Check out the git tag OTP-22.1.8.1, and build a full OTP system including documentation. Apply one or more applications from this build as patches to your installation using the 'otp_patch_apply' tool. For information on install requirements, see descriptions for each application version below. --------------------------------------------------------------------- --- snmp-5.4.3.1 ---------------------------------------------------- --------------------------------------------------------------------- The snmp-5.4.3.1 application can be applied independently of other applications on a full OTP 22 installation. --- Improvements and New Features --- OTP-16349 Application(s): snmp Related Id(s): ERIERL-444 Its now possible to remove selected varbinds (from the final message) when sending a notification. This is done by setting the 'value' (in the varbind(s) of the varbinds list) to '?NOTIFICATION_IGNORE_VB_VALUE'. OTP-16360 Application(s): snmp Related Id(s): ERIERL-451 Its now possible to specify that an oid shall be "truncated" (trailing ".0" to be removed) when sending an notification. Full runtime dependencies of snmp-5.4.3.1: crypto-3.3, erts-6.0, kernel-3.0, mnesia-4.12, runtime_tools-1.8.14, stdlib-2.5 --------------------------------------------------------------------- --------------------------------------------------------------------- --------------------------------------------------------------------- From joagre@REDACTED Fri Jan 10 11:24:22 2020 From: joagre@REDACTED (Joakim G.) Date: Fri, 10 Jan 2020 11:24:22 +0100 Subject: HOWTO/INSTALL-ANDROID.md seems broken in OTP-22.2 Message-ID: <49ec4d0d-740b-8533-f075-5f7496354c7d@gmail.com> FYI: I followed the build instructions in HOWTO/INSTALL-ANDROID.md in OTP-22.2 in order to build for Android. It eventually failed and it seems that there are missing global atoms in erts/emulator/nifs/common/socket_int.h starting on line 112, for example, the atom 'esock_atom_user' is undeclared. Cheers /Joakim What I got when I tried to follow the instructions in HOWTO/INSTALL-ANDROID.md $ pwd /home/jocke/src/erlang/otp_src_22.2 $ export NDK_ROOT=/usr/lib/android-ndk $ export PATH=$NDK_ROOT/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin:$PATH $ export NDK_PLAT=android-24 $ ./otp_build configure --xcomp-conf=./xcomp/erl-xcomp-arm-android.conf --without-ssl ... <> checking CFLAGS for -O switch... configure: error: ? CFLAGS must contain a -O flag. If you need to edit the CFLAGS you probably ? also want to add the default CFLAGS. The default CFLAGS are "-O2 -g". ? If you want to build erts without any optimization, pass -O0 to CFLAGS. ERROR: /home/jocke/src/erlang/otp_src_22.2/erts/configure failed! ./configure: 343: kill: No such process <> $ ./otp_build configure --xcomp-conf=./xcomp/erl-xcomp-arm-android.conf --without-ssl CFLAGS="-O2 -g" ... < ********************************************************************* **********************? APPLICATIONS DISABLED ********************** ********************************************************************* crypto???????? : User gave --without-ssl option odbc?????????? : ODBC library - link check failed ssh??????????? : User gave --without-ssl option ssl??????????? : User gave --without-ssl option ssl??????????? : User gave --without-ssl option ********************************************************************* ********************************************************************* **********************? APPLICATIONS INFORMATION ******************* ********************************************************************* wx???????????? : No OpenGL headers found, wx will NOT be usable No GLU headers (glu.h) found, wx will NOT be usable Cross compilation of the wx driver is not supported yet, wx will NOT be usable ********************************************************************* <> $ make noboot ... <> ?CC?? ?obj/arm-unknown-linux-androideabi/opt/smp/socket_dbg.o ?CC?? ?obj/arm-unknown-linux-androideabi/opt/smp/socket_tarray.o ?CC?? ?obj/arm-unknown-linux-androideabi/opt/smp/socket_util.o nifs/common/socket_util.c: In function 'esock_encode_packet_pkttype': nifs/common/socket_util.c:1495:21: error: 'esock_atom_user' undeclared (first use in this function) ???????? *ePktType = esock_atom_user; <> From ostinelli@REDACTED Fri Jan 10 13:16:36 2020 From: ostinelli@REDACTED (Roberto Ostinelli) Date: Fri, 10 Jan 2020 13:16:36 +0100 Subject: [ANN] Syn 2.1 Message-ID: All, Syn v2.1 has just been released. The main highlights are: - The mnesia dependency has been removed in favor of ETS tables. - Conflict resolution has been further improved, and now it also uses a basic system clock to compare and resolve conflicts (this mechanism can be improved with custom implementations such as vclocks if the native one is considered to be insufficient). - Experimental anti-entropy support. - Additional helper methods have been added for SysOps. This is a recommended update. You can find it in the usual places: https://github.com/ostinelli/syn https://hex.pm/packages/syn Best, r. -------------- next part -------------- An HTML attachment was scrubbed... URL: From micael.karlberg@REDACTED Fri Jan 10 13:56:00 2020 From: micael.karlberg@REDACTED (Micael Karlberg) Date: Fri, 10 Jan 2020 13:56:00 +0100 Subject: esock_atom_user problem and Android builds In-Reply-To: <4c3e4f15-63a5-0cc8-313e-668d632e1068@gmail.com> References: <4c3e4f15-63a5-0cc8-313e-668d632e1068@gmail.com> Message-ID: Hi, It seems you are correct. Those kind of atoms are (supposed to be) created: GLOBAL_ATOM_DEFS (in socket_int.h) GLOBAL_ATOMS (in socket_nif.c) Must have missed one :( Regards, /BMK On 2020-01-09 14:43, Joakim G. wrote: > Hi, > I'm trying to cross compile BEAM for Android but I'm stuck on a compile error. > > It seems that 'esock_atom_user' is undeclared and I can not even find any decalartion of it on the > emulator/erts code. > > Can anyone point me in the right direction? > > Cheers > /Joakim > > jocke@REDACTED:~/src/erlang/otp_src_22.2$ make noboot > make USE_PGO=false BOOT_PREFIX= build_erl_interface emulator libs local_setup > ... > make[4]: G?r till katalogen ?/home/jocke/src/erlang/otp_src_22.2/erts/emulator? > ?MAKE?? ?opt > make[5]: G?r till katalogen ?/home/jocke/src/erlang/otp_src_22.2/erts/emulator? > ?GEN?? ?arm-unknown-linux-androideabi/gen_git_version.mk > ?CC?? ?obj/arm-unknown-linux-androideabi/opt/smp/socket_util.o > nifs/common/socket_util.c: In function 'esock_encode_packet_pkttype': > nifs/common/socket_util.c:1495:21: error: 'esock_atom_user' undeclared (first use in this function) > ???????? *ePktType = esock_atom_user; > > From alex@REDACTED Fri Jan 10 15:30:08 2020 From: alex@REDACTED (alex@REDACTED) Date: Fri, 10 Jan 2020 09:30:08 -0500 Subject: build erlang otp 22.2 but can't used observer In-Reply-To: References: <1adba854-4e7e-5419-f6b2-ad0405e0839e@xbasics.com> <98a39b88748db1fc2c5f3a33e0249d17@smtp.hushmail.com> Message-ID: <2c02d00ac50357ef056aab12aaa44928@smtp.hushmail.com> If you ran "configure" for wxWidgets as your Ref indicates (with --disable-share), you didn't compile the shared libraries for Erlang to use.? You need the "--enable-shared" flag instead and place all the variables right in front of the "configure" command. Cheers, Alex On 1/9/20 11:18 PM, Rareman S wrote: > Hi Alex > Thanks for help. Kerl/asdf need to connected to the internet right? I > cannot direct connect to the internet for some reason. Current I did > fixed some here below. > > checking for wx/stc/stc.h... yes > checking if we can link wxwidgets programs... no > > Above if see previous mail? ? "wx/stc/stc.h... no " i changed gcc from > 4.8 to 4.5. how to link wxwidgets programs? > > **Ref > ./configure CC=/usr/gcc/4.5/bin/gcc CXX=/usr/gcc/4.5/bin/g++ > CFLAGS=-fPIC CXXFLAGS=-fPIC --with-opengl --enable-unicode > --enable-graphics_ctx --enable-gnomeprint --disable-shared > --disable-optimise > > ???????? ?. 4 ?.?. 2020 ???? 14:28 alex@REDACTED > > > ????????: > > BTW, I should've mentioned also to try using a solution like kerl > (https://github.com/kerl/kerl) or maybe asdf > (https://github.com/asdf-vm/asdf). That might be of help! > > Cheers, > Alex > > On 1/3/20 5:26 PM, alex@REDACTED wrote: >> Something to point out is that wxWidgets (wx) version 3.1.3 is a >> development version and in overall you want to stick with stable >> version 3.0.4.? Don't remember if Erlang has an issue with 3.1.3, >> but I know I've run into problems with other software that >> depends on wx.? Once you compile wx and install it as root (if >> you didn't use a --prefix location, it should install under >> /usr/local). Thus, wx-config should default to /usr/local/bin.? >> Now, it's up to your system config to have those paths >> available.? You can run ldconfig from the console/terminal you're >> using for this process or simply reboot to make sure the >> libraries are made available. Note again that you might need to >> use /etc/ld.so.conf to make /usr/local/{lib, lib64} available for >> dynamic linking.? From there on, just configure the Erlang as >> stated.? Note that the github version of Erlang doesn't bring a >> configure file with it.? You need to run "otp_build autoconf" >> from its base directory first. >> >> Cheers, >> Alex >> >> On 1/2/20 5:04 AM, Rareman S wrote: >>> Hi, >>> >>> >>> here build?wxWidgets-3.1.3? successful? I give some output (full >>> in attached) and/or configure options below also i tried build >>> simple configure option still can't used wx on otp22.2. On >>> solaris didn't have ldconfig or ld.so.conf >>> Question >>> How to put/integrate new wx3.1.3 into otp22? (i just create new >>> symbolic link remove the old) >>> >>> REF >>> ./configure --with-opengl --with-gtk=3 --enable-stc >>> --enable-webview ?--enable-shared --enable-compat28 >>> ?wx-config --version >>> 3.1.3 >>> wx-config --list >>> >>> ? ? Default config is gtk3-unicode-3.1 >>> >>> ? Default config in /export/home/itmxadm/WX/wxWidgets-3.1.3 will >>> be used for output >>> >>> ? Alternate matches: >>> ? ? gtk2-ansi-3.1 >>> ? ? gtk2-unicode-3.1 >>> ?wx-config --libs >>> -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib -pthreads >>> -Wl,-rpath,/export/home/itmxadm/WX/wxWidgets-3.1.3/lib >>> -lwx_gtk3u_xrc-3.1 -lwx_gtk3u_html-3.1 -lwx_gtk3u_qa-3.1 >>> -lwx_gtk3u_core-3.1 -lwx_baseu_xml-3.1 -lwx_baseu_net-3.1 >>> -lwx_baseu-3.1 >>> >>> /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o >>> richtextdll_richtextstyledlg.o ?-D__WXGTK__ ? ? ?-DWXBUILDING ? >>> ? ?-I./src/regex ?-DWXUSINGDLL -DWXMAKINGDLL_RICHTEXT -fPIC >>> -DPIC -Wall -Wundef -Wunused-parameter -Wno-ctor-dtor-privacy >>> -Woverloaded-virtual -Wno-deprecated-declarations >>> -D_FILE_OFFSET_BITS=64 >>> -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 >>> -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >>> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >>> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >>> -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo >>> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 >>> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >>> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include >>> -I/usr/include/harfbuzz -I/usr/include/freetype2 >>> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >>> -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem >>> /usr/openwin/include -I/usr/openwin/include -pthreads >>> -D_REENTRANT -O2 >>> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >>> -I/usr/include/freetype2 -I/usr/include/pango-1.0 >>> -I/usr/include/harfbuzz -I/usr/include/glib-2.0 >>> -I/usr/lib/glib-2.0/include -D_REENTRANT >>> -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_PTHREADS >>> -D_POSIX_PTHREAD_SEMANTICS -I/usr/include/gtk-3.0/unix-print >>> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >>> -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 >>> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >>> -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 >>> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >>> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include >>> -I/usr/include/harfbuzz -I/usr/include/freetype2 >>> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >>> -I/usr/include/pixman-1 -I/usr/include/libpng14 >>> -fvisibility=hidden -fvisibility-inlines-hidden >>> ./src/richtext/richtextstyledlg.cpp >>> /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o >>> richtextdll_richtextstyles.o ?-D__WXGTK__ ?-DWXBUILDING ? ? >>> ?-I./src/regex ?-DWXUSINGDLL -DWXMAKINGDLL_RICHTEXT -fPIC -DPIC >>> -Wall -Wundef -Wunused-parameter -Wno-ctor-dtor-privacy >>> -Woverloaded-virtual -Wno-deprecated-declarations >>> -D_FILE_OFFSET_BITS=64 >>> -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 >>> -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >>> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >>> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >>> -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo >>> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 >>> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >>> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include >>> -I/usr/include/harfbuzz -I/usr/include/freetype2 >>> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >>> -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem >>> /usr/openwin/include -I/usr/openwin/include -pthreads >>> -D_REENTRANT -O2 >>> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >>> -I/usr/include/freetype2 -I/usr/include/pango-1.0 >>> -I/usr/include/harfbuzz -I/usr/include/glib-2.0 >>> -I/usr/lib/glib-2.0/include -D_REENTRANT >>> -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_PTHREADS >>> -D_POSIX_PTHREAD_SEMANTICS -I/usr/include/gtk-3.0/unix-print >>> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >>> -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 >>> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >>> -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 >>> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >>> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include >>> -I/usr/include/harfbuzz -I/usr/include/freetype2 >>> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >>> -I/usr/include/pixman-1 -I/usr/include/libpng14 >>> -fvisibility=hidden -fvisibility-inlines-hidden >>> ./src/richtext/richtextstyles.cpp >>> /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o >>> richtextdll_richtextsymboldlg.o ?-D__WXGTK__ ? ?-DWXBUILDING ? ? >>> ?-I./src/regex ?-DWXUSINGDLL -DWXMAKINGDLL_RICHTEXT -fPIC -DPIC >>> -Wall -Wundef -Wunused-parameter -Wno-ctor-dtor-privacy >>> -Woverloaded-virtual -Wno-deprecated-declarations >>> -D_FILE_OFFSET_BITS=64 >>> -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 >>> -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >>> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >>> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >>> -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo >>> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 >>> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >>> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include >>> -I/usr/include/harfbuzz -I/usr/include/freetype2 >>> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >>> -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem >>> /usr/openwin/include -I/usr/openwin/include -pthreads >>> -D_REENTRANT -O2 >>> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >>> -I/usr/include/freetype2 -I/usr/include/pango-1.0 >>> -I/usr/include/harfbuzz -I/usr/include/glib-2.0 >>> -I/usr/lib/glib-2.0/include -D_REENTRANT >>> -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_PTHREADS >>> -D_POSIX_PTHREAD_SEMANTICS -I/usr/include/gtk-3.0/unix-print >>> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >>> -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 >>> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >>> -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 >>> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >>> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include >>> -I/usr/include/harfbuzz -I/usr/include/freetype2 >>> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >>> -I/usr/include/pixman-1 -I/usr/include/libpng14 >>> -fvisibility=hidden -fvisibility-inlines-hidden >>> ./src/richtext/richtextsymboldlg.cpp >>> /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o >>> richtextdll_richtextxml.o ?-D__WXGTK__ ?-DWXBUILDING ? ? >>> ?-I./src/regex ?-DWXUSINGDLL -DWXMAKINGDLL_RICHTEXT -fPIC -DPIC >>> -Wall -Wundef -Wunused-parameter -Wno-ctor-dtor-privacy >>> -Woverloaded-virtual -Wno-deprecated-declarations >>> -D_FILE_OFFSET_BITS=64 >>> -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 >>> -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >>> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >>> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >>> -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo >>> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 >>> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >>> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include >>> -I/usr/include/harfbuzz -I/usr/include/freetype2 >>> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >>> -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem >>> /usr/openwin/include -I/usr/openwin/include -pthreads >>> -D_REENTRANT -O2 >>> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >>> -I/usr/include/freetype2 -I/usr/include/pango-1.0 >>> -I/usr/include/harfbuzz -I/usr/include/glib-2.0 >>> -I/usr/lib/glib-2.0/include -D_REENTRANT >>> -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_PTHREADS >>> -D_POSIX_PTHREAD_SEMANTICS -I/usr/include/gtk-3.0/unix-print >>> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >>> -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 >>> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >>> -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 >>> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >>> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include >>> -I/usr/include/harfbuzz -I/usr/include/freetype2 >>> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >>> -I/usr/include/pixman-1 -I/usr/include/libpng14 >>> -fvisibility=hidden -fvisibility-inlines-hidden >>> ./src/richtext/richtextxml.cpp >>> /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o >>> richtextdll_xh_richtext.o ?-D__WXGTK__ ?-DWXBUILDING ? ? >>> ?-I./src/regex ?-DWXUSINGDLL -DWXMAKINGDLL_RICHTEXT -fPIC -DPIC >>> -Wall -Wundef -Wunused-parameter -Wno-ctor-dtor-privacy >>> -Woverloaded-virtual -Wno-deprecated-declarations >>> -D_FILE_OFFSET_BITS=64 >>> -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 >>> -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >>> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >>> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >>> -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo >>> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 >>> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >>> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include >>> -I/usr/include/harfbuzz -I/usr/include/freetype2 >>> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >>> -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem >>> /usr/openwin/include -I/usr/openwin/include -pthreads >>> -D_REENTRANT -O2 >>> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >>> -I/usr/include/freetype2 -I/usr/include/pango-1.0 >>> -I/usr/include/harfbuzz -I/usr/include/glib-2.0 >>> -I/usr/lib/glib-2.0/include -D_REENTRANT >>> -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_PTHREADS >>> -D_POSIX_PTHREAD_SEMANTICS -I/usr/include/gtk-3.0/unix-print >>> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >>> -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 >>> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >>> -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 >>> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >>> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include >>> -I/usr/include/harfbuzz -I/usr/include/freetype2 >>> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >>> -I/usr/include/pixman-1 -I/usr/include/libpng14 >>> -fvisibility=hidden -fvisibility-inlines-hidden >>> ./src/xrc/xh_richtext.cpp >>> g++ -shared -fPIC -o >>> /export/home/itmxadm/WX/wxWidgets-3.1.3/lib/libwx_gtk3u_richtext-3.1.so.3 >>> ?richtextdll_richtextbuffer.o richtextdll_richtextctrl.o >>> richtextdll_richtextformatdlg.o richtextdll_richtexthtml.o >>> richtextdll_richtextimagedlg.o richtextdll_richtextprint.o >>> richtextdll_richtextstyledlg.o richtextdll_richtextstyles.o >>> richtextdll_richtextsymboldlg.o richtextdll_richtextxml.o >>> richtextdll_xh_richtext.o >>> -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib >>> -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib >>> -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib >>> -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib >>> ?-L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib ? -h >>> libwx_gtk3u_richtext-3.1.so.3 ?-pthreads -lgtk-3 -lgdk-3 >>> -latk-1.0 -lgio-2.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 >>> -lcairo-gobject -lpango-1.0 -lcairo -lgobject-2.0 -lgthread-2.0 >>> -lpthread -lglib-2.0 -lX11 -lXxf86vm -lSM -lgtk-3 -lgdk-3 >>> -latk-1.0 -lgio-2.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 >>> -lcairo-gobject -lpango-1.0 -lcairo -lgobject-2.0 -lglib-2.0 >>> -lXtst -lpangoft2-1.0 -lpango-1.0 -lfontconfig -lgobject-2.0 >>> -lglib-2.0 -lfreetype -lpng -lz -ljpeg -ltiff -llzma >>> ?-lwxregexu-3.1 ?-pthreads ? ?-lz -lnsl -lsocket -llzma -lm >>> ?-lwx_gtk3u_html-3.1 -lwx_baseu_xml-3.1 -lwx_gtk3u_core-3.1 >>> -lwx_baseu-3.1 -lz -lnsl -lsocket -llzma -lm >>> (cd /export/home/itmxadm/WX/wxWidgets-3.1.3/lib/; rm -f >>> libwx_gtk3u_richtext-3.1.so >>> ; ln -s >>> libwx_gtk3u_richtext-3.1.so.3 libwx_gtk3u_richtext-3.1.so >>> ) >>> /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o >>> stcdll_stc.o ?-D__WXGTK__ ? ? ?-DWXBUILDING ? ?-I./src/regex >>> ?-I./src/stc/scintilla/include -I./src/stc/scintilla/lexlib >>> -I./src/stc/scintilla/src -D__WX__ -DSCI_LEXER -DNO_CXX11_REGEX >>> -DLINK_LEXERS -DWXUSINGDLL -DWXMAKINGDLL_STC -fPIC -DPIC -Wall >>> -Wundef -Wunused-parameter -Wno-ctor-dtor-privacy >>> -Woverloaded-virtual -Wno-deprecated-declarations >>> -D_FILE_OFFSET_BITS=64 >>> -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 >>> -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >>> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >>> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >>> -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo >>> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 >>> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >>> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include >>> -I/usr/include/harfbuzz -I/usr/include/freetype2 >>> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >>> -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem >>> /usr/openwin/include -I/usr/openwin/include -pthreads >>> -D_REENTRANT -O2 >>> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >>> -I/usr/include/freetype2 -I/usr/include/pango-1.0 >>> -I/usr/include/harfbuzz -I/usr/include/glib-2.0 >>> -I/usr/lib/glib-2.0/include -D_REENTRANT >>> -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_PTHREADS >>> -D_POSIX_PTHREAD_SEMANTICS -I/usr/include/gtk-3.0/unix-print >>> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >>> -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 >>> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >>> -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 >>> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >>> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include >>> -I/usr/include/harfbuzz -I/usr/include/freetype2 >>> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >>> -I/usr/include/pixman-1 -I/usr/include/libpng14 >>> -fvisibility=hidden -fvisibility-inlines-hidden ./src/stc/stc.cpp >>> /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o >>> stcdll_PlatWX.o ?-D__WXGTK__ ? ? ?-DWXBUILDING ? ? >>> ?-I./src/regex ?-I./src/stc/scintilla/include >>> -I./src/stc/scintilla/lexlib -I./src/stc/scintilla/src -D__WX__ >>> -DSCI_LEXER -DNO_CXX11_REGEX -DLINK_LEXERS -DWXUSINGDLL >>> -DWXMAKINGDLL_STC -fPIC -DPIC -Wall -Wundef -Wunused-parameter >>> -Wno-ctor-dtor-privacy -Woverloaded-virtual >>> -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=64 >>> -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 >>> -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >>> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >>> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >>> -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo >>> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 >>> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >>> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include >>> -I/usr/include/harfbuzz -I/usr/include/freetype2 >>> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >>> -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem >>> /usr/openwin/include -I/usr/openwin/include -pthreads >>> -D_REENTRANT -O2 >>> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >>> -I/usr/include/freetype2 -I/usr/include/pango-1.0 >>> -I/usr/include/harfbuzz -I/usr/include/glib-2.0 >>> -I/usr/lib/glib-2.0/include -D_REENTRANT >>> -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_PTHREADS >>> -D_POSIX_PTHREAD_SEMANTICS -I/usr/include/gtk-3.0/unix-print >>> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >>> -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 >>> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >>> -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 >>> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >>> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include >>> -I/usr/include/harfbuzz -I/usr/include/freetype2 >>> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >>> -I/usr/include/pixman-1 -I/usr/include/libpng14 >>> -fvisibility=hidden -fvisibility-inlines-hidden ./src/stc/PlatWX.cpp >>> /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o >>> stcdll_ScintillaWX.o ?-D__WXGTK__ ?-DWXBUILDING ? ? >>> ?-I./src/regex ?-I./src/stc/scintilla/include >>> -I./src/stc/scintilla/lexlib -I./src/stc/scintilla/src -D__WX__ >>> -DSCI_LEXER -DNO_CXX11_REGEX -DLINK_LEXERS -DWXUSINGDLL >>> -DWXMAKINGDLL_STC -fPIC -DPIC -Wall -Wundef -Wunused-parameter >>> -Wno-ctor-dtor-privacy -Woverloaded-virtual >>> -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=64 >>> -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 >>> -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >>> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >>> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >>> -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo >>> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 >>> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >>> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include >>> -I/usr/include/harfbuzz -I/usr/include/freetype2 >>> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >>> -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem >>> /usr/openwin/include -I/usr/openwin/include -pthreads >>> -D_REENTRANT -O2 >>> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >>> -I/usr/include/freetype2 -I/usr/include/pango-1.0 >>> -I/usr/include/harfbuzz -I/usr/include/glib-2.0 >>> -I/usr/lib/glib-2.0/include -D_REENTRANT >>> -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_PTHREADS >>> -D_POSIX_PTHREAD_SEMANTICS -I/usr/include/gtk-3.0/unix-print >>> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >>> -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 >>> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >>> -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 >>> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >>> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include >>> -I/usr/include/harfbuzz -I/usr/include/freetype2 >>> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >>> -I/usr/include/pixman-1 -I/usr/include/libpng14 >>> -fvisibility=hidden -fvisibility-inlines-hidden >>> ./src/stc/ScintillaWX.cpp >>> g++ -shared -fPIC -o >>> /export/home/itmxadm/WX/wxWidgets-3.1.3/lib/libwx_gtk3u_stc-3.1.so.3 >>> ?stcdll_stc.o stcdll_PlatWX.o stcdll_ScintillaWX.o >>> ?-L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib >>> -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib >>> -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib >>> ?-L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib ? -h >>> libwx_gtk3u_stc-3.1.so.3 ?-pthreads ? ? ? ? -lgtk-3 -lgdk-3 >>> -latk-1.0 -lgio-2.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 >>> -lcairo-gobject -lpango-1.0 -lcairo -lgobject-2.0 -lgthread-2.0 >>> -lpthread -lglib-2.0 -lX11 -lXxf86vm -lSM -lgtk-3 -lgdk-3 >>> -latk-1.0 -lgio-2.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 >>> -lcairo-gobject -lpango-1.0 -lcairo -lgobject-2.0 -lglib-2.0 >>> -lXtst -lpangoft2-1.0 -lpango-1.0 -lfontconfig -lgobject-2.0 >>> -lglib-2.0 -lfreetype -lpng -lz -ljpeg -ltiff -llzma >>> ?-lwxregexu-3.1 ?-pthreads ? ?-lz -lnsl -lsocket -llzma -lm >>> ?-lwxscintilla-3.1 -lwx_gtk3u_core-3.1 -lwx_baseu-3.1 -lz -lnsl >>> -lsocket -llzma -lm >>> (cd /export/home/itmxadm/WX/wxWidgets-3.1.3/lib/; rm -f >>> libwx_gtk3u_stc-3.1.so ; ln -s >>> libwx_gtk3u_stc-3.1.so.3 libwx_gtk3u_stc-3.1.so >>> ) >>> /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o >>> gldll_glcmn.o ?-D__WXGTK__ ? ? ?-DWXBUILDING ? ?-I./src/regex >>> ?-DWXUSINGDLL -DWXMAKINGDLL_GL -fPIC -DPIC -Wall -Wundef >>> -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual >>> -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=64 >>> -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 >>> -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >>> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >>> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >>> -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo >>> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 >>> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >>> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include >>> -I/usr/include/harfbuzz -I/usr/include/freetype2 >>> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >>> -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem >>> /usr/openwin/include -I/usr/openwin/include -pthreads >>> -D_REENTRANT -O2 >>> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >>> -I/usr/include/freetype2 -I/usr/include/pango-1.0 >>> -I/usr/include/harfbuzz -I/usr/include/glib-2.0 >>> -I/usr/lib/glib-2.0/include -D_REENTRANT >>> -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_PTHREADS >>> -D_POSIX_PTHREAD_SEMANTICS -I/usr/include/gtk-3.0/unix-print >>> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >>> -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 >>> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >>> -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 >>> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >>> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include >>> -I/usr/include/harfbuzz -I/usr/include/freetype2 >>> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >>> -I/usr/include/pixman-1 -I/usr/include/libpng14 >>> -fvisibility=hidden -fvisibility-inlines-hidden >>> ./src/common/glcmn.cpp >>> /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o >>> gldll_glx11.o ?-D__WXGTK__ ? ? ?-DWXBUILDING ? ?-I./src/regex >>> ?-DWXUSINGDLL -DWXMAKINGDLL_GL -fPIC -DPIC -Wall -Wundef >>> -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual >>> -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=64 >>> -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 >>> -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >>> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >>> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >>> -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo >>> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 >>> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >>> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include >>> -I/usr/include/harfbuzz -I/usr/include/freetype2 >>> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >>> -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem >>> /usr/openwin/include -I/usr/openwin/include -pthreads >>> -D_REENTRANT -O2 >>> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >>> -I/usr/include/freetype2 -I/usr/include/pango-1.0 >>> -I/usr/include/harfbuzz -I/usr/include/glib-2.0 >>> -I/usr/lib/glib-2.0/include -D_REENTRANT >>> -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_PTHREADS >>> -D_POSIX_PTHREAD_SEMANTICS -I/usr/include/gtk-3.0/unix-print >>> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >>> -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 >>> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >>> -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 >>> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >>> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include >>> -I/usr/include/harfbuzz -I/usr/include/freetype2 >>> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >>> -I/usr/include/pixman-1 -I/usr/include/libpng14 >>> -fvisibility=hidden -fvisibility-inlines-hidden ./src/unix/glx11.cpp >>> /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o >>> gldll_gtk_glcanvas.o ?-D__WXGTK__ ?-DWXBUILDING ? ? >>> ?-I./src/regex ?-DWXUSINGDLL -DWXMAKINGDLL_GL -fPIC -DPIC -Wall >>> -Wundef -Wunused-parameter -Wno-ctor-dtor-privacy >>> -Woverloaded-virtual -Wno-deprecated-declarations >>> -D_FILE_OFFSET_BITS=64 >>> -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 >>> -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >>> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >>> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >>> -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo >>> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 >>> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >>> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include >>> -I/usr/include/harfbuzz -I/usr/include/freetype2 >>> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >>> -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem >>> /usr/openwin/include -I/usr/openwin/include -pthreads >>> -D_REENTRANT -O2 >>> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >>> -I/usr/include/freetype2 -I/usr/include/pango-1.0 >>> -I/usr/include/harfbuzz -I/usr/include/glib-2.0 >>> -I/usr/lib/glib-2.0/include -D_REENTRANT >>> -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_PTHREADS >>> -D_POSIX_PTHREAD_SEMANTICS -I/usr/include/gtk-3.0/unix-print >>> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >>> -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 >>> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >>> -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 >>> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >>> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include >>> -I/usr/include/harfbuzz -I/usr/include/freetype2 >>> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >>> -I/usr/include/pixman-1 -I/usr/include/libpng14 >>> -fvisibility=hidden -fvisibility-inlines-hidden >>> ./src/gtk/glcanvas.cpp >>> g++ -shared -fPIC -o >>> /export/home/itmxadm/WX/wxWidgets-3.1.3/lib/libwx_gtk3u_gl-3.1.so.3 >>> ?gldll_glcmn.o gldll_glx11.o gldll_gtk_glcanvas.o >>> ?-L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib ? -h >>> libwx_gtk3u_gl-3.1.so.3 ?-pthreads ? ? ? ? -lgtk-3 -lgdk-3 >>> -latk-1.0 -lgio-2.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 >>> -lcairo-gobject -lpango-1.0 -lcairo -lgobject-2.0 -lgthread-2.0 >>> -lpthread -lglib-2.0 -lX11 -lXxf86vm -lSM -lgtk-3 -lgdk-3 >>> -latk-1.0 -lgio-2.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 >>> -lcairo-gobject -lpango-1.0 -lcairo -lgobject-2.0 -lglib-2.0 >>> -lXtst -lpangoft2-1.0 -lpango-1.0 -lfontconfig -lgobject-2.0 >>> -lglib-2.0 -lfreetype -lpng -lz -ljpeg -ltiff -llzma >>> ?-lwxregexu-3.1 ?-pthreads ? ?-lz -lnsl -lsocket -llzma -lm >>> ?-lwx_gtk3u_core-3.1 -lwx_baseu-3.1 ?-lGL -lGLU -lz -lnsl >>> -lsocket -llzma -lm >>> (cd /export/home/itmxadm/WX/wxWidgets-3.1.3/lib/; rm -f >>> libwx_gtk3u_gl-3.1.so ; ln -s >>> libwx_gtk3u_gl-3.1.so.3 libwx_gtk3u_gl-3.1.so >>> ) >>> (if test -f utils/wxrc/Makefile ; then cd utils/wxrc && >>> /usr/bin/gmake all ; fi) >>> gmake[1]: Entering directory >>> `/export/home/itmxadm/WX/wxWidgets-3.1.3/utils/wxrc' >>> /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o >>> wxrc_wxrc.o -D__WXGTK__ ? ? ?-I. -DWXUSINGDLL -DwxUSE_GUI=0 >>> -Wall -Wundef -Wunused-parameter -Wno-ctor-dtor-privacy >>> -Woverloaded-virtual -Wno-deprecated-declarations >>> -D_FILE_OFFSET_BITS=64 >>> -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 >>> -I../../include -D_REENTRANT -D_PTHREADS >>> -D_POSIX_PTHREAD_SEMANTICS -I/usr/include/gtk-3.0 >>> -I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0 >>> -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ >>> -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 >>> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include >>> -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 >>> -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz >>> -I/usr/include/freetype2 >>> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >>> -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem >>> /usr/openwin/include -I/usr/openwin/include -pthreads >>> -D_REENTRANT -O2 >>> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >>> -I/usr/include/freetype2 -I/usr/include/pango-1.0 >>> -I/usr/include/harfbuzz -I/usr/include/glib-2.0 >>> -I/usr/lib/glib-2.0/include -D_REENTRANT >>> -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_PTHREADS >>> -D_POSIX_PTHREAD_SEMANTICS -I/usr/include/gtk-3.0/unix-print >>> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >>> -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 >>> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >>> -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 >>> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >>> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include >>> -I/usr/include/harfbuzz -I/usr/include/freetype2 >>> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >>> -I/usr/include/pixman-1 -I/usr/include/libpng14 >>> -fvisibility=hidden -fvisibility-inlines-hidden ./wxrc.cpp >>> g++ -o wxrc wxrc_wxrc.o >>> ?-L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib ?-pthreads ? ? >>> -lwx_baseu_xml-3.1 -lexpat -lwx_baseu-3.1 ? ? -lwxregexu-3.1 >>> ?-pthreads ? ?-lz -lnsl -lsocket -llzma -lm ?-lz -lnsl -lsocket >>> -llzma -lm >>> gmake[1]: Leaving directory >>> `/export/home/itmxadm/WX/wxWidgets-3.1.3/utils/wxrc' >>> >>> >>> >>> ???????? ?. 31 ?.?. 2019 ???? 04:33 alex@REDACTED >>> >> > ????????: >>> >>> Oops, disregard the $wk, $stl and $st variable calls.? >>> Sorry, but I'm half awake, half sleep.? Actually "st" is for >>> enabling shared library, which is needed.? See below... >>> >>> On 12/30/19 4:24 PM, alex@REDACTED >>> wrote: >>>> Yeah, looks like it cannot find the wx shared libraries.? >>>> Verify the location of the wx files.? You might need to >>>> configure /etc/ld.so.conf to identify where they are >>>> located.? For reference, I personally compile wxWidgets >>>> from scratch with GTK3 and Mesa already installed with... >>>> >>>> export CFLAGS="-O3 -fPIC -march=native -pipe" >>>> export CXXFLAGS="$CFLAGS" >>>> >>>> CFLAGS CXXFLAGS ./configure \ >>>> --prefix=/usr \ >>>> ? --libdir=/usr/lib64 \ >>>> ? --sysconfdir=/etc \ >>>> ? --enable-mediactrl \ >>>> ? --with-opengl \ >>>> ? --enable-graphics_ctx \ >>>> ? --with-gtk=3 \ >>>> ? --enable-unicode \ >>>> ? --enable-compat28 \ >>>> ? --enable-plugins \ >>>> ? --enable-stc \ >>>> ? --enable-webview \ >>> ???? --enable-shared >>>> >>>> BTW, the configuration I use to compile Erlang is... >>>> >>>> CFLAGS ./configure \ >>>> ? --prefix=/usr \ >>>> ? --libdir=/usr/lib64 \ >>>> ? --without-odbc \ >>>> ? --without-megaco \ >>>> ? --enable-threads \ >>>> ? --enable-dirty-schedulers \ >>>> ? --enable-smp-support \ >>>> ? --enable-hipe >>>> >>>> ...follow by make and make install.? These are part of >>>> bigger scripts I use to make packages for my Linux distro, >>>> but this is practically it. >>>> >>>> Cheers, >>>> Alex >>>> >>>> On 12/30/19 11:48 AM, Mikael Pettersson wrote: >>>>> On Mon, Dec 30, 2019 at 4:48 PM Rareman S wrote: >>>>>> Hi, >>>>>> >>>>>> Here is my pre-build with erlang OTP22.2. >>>>> ... >>>>>> === Running configure in /export/home/itmxadm/otp-OTP-22.2/lib/wx === >>>>> ... >>>>>> checking if we can link wxwidgets programs... no >>>>>> configure: creating sparc-sun-solaris2.11/config.status >>>>>> config.status: creatingconfig.mk >>>>>> config.status: creating c_src/Makefile >>>>>> configure: WARNING: Can not find wx/stc/stc.h -Wall -fPIC -O -Wno-deprecated-declarations -fomit-frame-pointer -fno-strict-aliasing -D_GNU_SOURCE -D_THREAD_SAFE -D_REENTRANT -I/export/home/itmxadm/WX/wxWidgets-3.1.3/build_x11/lib/wx/include/x11univ-unicode-3.1 -I/export/home/itmxadm/WX/wxWidgets-3.1.3/include -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXUNIVERSAL__ -D__WXX11__ -pthreads -D_REENTRANT >>>>>> configure: WARNING: Can not link wx program are all developer packages installed? >>>>> ... >>>>>> wx : wxWidgets don't have gl support, wx will NOT be useable >>>>>> wxWidgets don't have wxStyledTextControl (stc.h), wx will NOT be useable >>>>>> Can not link the wx driver, wx will NOT be useable >>>>> ... >>>>>> ./configure CC=${IDE_CC} CXX=${IDE_CXX} CFLAGS="-O" CXXFLAGS=-g --enable-compat28 --prefix=/usr/local. Above config above after build successful can't used wx. >>>>> Given the wx-related warnings above, it's not surprising that wx >>>>> doesn't work for you. You'll need to inspect the config.log file for >>>>> lib/wx/ so see what the errors were, but off-hand it looks like an >>>>> incomplete wxWidgets installation. >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ostinelli@REDACTED Fri Jan 10 16:37:42 2020 From: ostinelli@REDACTED (Roberto Ostinelli) Date: Fri, 10 Jan 2020 16:37:42 +0100 Subject: ETS tuple in body Message-ID: Dear list, Something I probably should know better of. In ETS, if one of your MatchBody is a tuple, it needs to be wrapped as a tuple: MatchBody = case is_tuple(Name) of true -> {{{Name}, '$2', '$3', '$4'}}; _ -> {{Name, '$2', '$3', '$4'}} end, case ets:select(my_table, [{ {Name, '$2', '$3', '$4', '_', '_'}, [], [MatchBody] }]) I need to do this because to make it work for Name values of both test and {test}. Is there a better way? Thank you, r. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jacob01@REDACTED Fri Jan 10 17:05:49 2020 From: jacob01@REDACTED (Jacob) Date: Fri, 10 Jan 2020 17:05:49 +0100 Subject: ETS tuple in body In-Reply-To: References: Message-ID: <8659623c-5138-067e-805b-b7d9515c7233@gmx.net> Hi, On 1/10/20 4:37 PM, Roberto Ostinelli wrote: > ? ? MatchBody = case is_tuple(Name) of > ? ? ? ? true -> {{{Name}, '$2', '$3', '$4'}}; > ? ? ? ? _ -> {{Name, '$2', '$3', '$4'}} > ? ? end, > ? ? case ets:select(my_table, [{ > ? ? ? ? {Name, '$2', '$3', '$4', '_', '_'}, > ? ? ? ? [], > ? ? ? ? [MatchBody] > ? ? }]) > > I need to do this because to make it work for Name values of both test > and {test}. > Is there a better way? yes, by using a 'const' expression that will prevent variable substition and function (tuple) evaluation in the sub-expression (here Name): ? ? case ets:select(my_table, [{ ? ? ? ? {Name, '$2', '$3', '$4', '_', '_'}, ? ? ? ? [], ? ? ? ? [{{const, Name}, '$2', '$3', '$4'}] ? ? }]) I assume there aren't nested tuples in Name, but just using {Name} like above would only prevent the outmost tuple from being interpreted as a "function" or variable. The 'const' expression is much safer here, since it just says: "include as is". See the ms_transform manpage for details. Jacob From ostinelli@REDACTED Fri Jan 10 17:17:58 2020 From: ostinelli@REDACTED (Roberto Ostinelli) Date: Fri, 10 Jan 2020 17:17:58 +0100 Subject: ETS tuple in body In-Reply-To: <8659623c-5138-067e-805b-b7d9515c7233@gmx.net> References: <8659623c-5138-067e-805b-b7d9515c7233@gmx.net> Message-ID: Thank you Jacob, I already tried a couple of combinations with const but I always got an error message. For instance: (r@REDACTED)2> Name = test. test (r@REDACTED)3> ets:select(my_table, [{ (r@REDACTED)3> {Name, '$2', '$3', '$4', '_', '_'}, (r@REDACTED)3> [], (r@REDACTED)3> [{{const, Name}, '$2', '$3', '$4'}] (r@REDACTED)3> }]). ** exception error: bad argument in function ets:select/2 called as ets:select(my_table, [{{test,'$2','$3','$4','_','_'}, [], [{{const,test},'$2','$3','$4'}]}]) On Fri, Jan 10, 2020 at 5:05 PM Jacob wrote: > Hi, > > On 1/10/20 4:37 PM, Roberto Ostinelli wrote: > > MatchBody = case is_tuple(Name) of > > true -> {{{Name}, '$2', '$3', '$4'}}; > > _ -> {{Name, '$2', '$3', '$4'}} > > end, > > case ets:select(my_table, [{ > > {Name, '$2', '$3', '$4', '_', '_'}, > > [], > > [MatchBody] > > }]) > > > > I need to do this because to make it work for Name values of both test > > and {test}. > > Is there a better way? > > yes, by using a 'const' expression that will prevent variable substition > and function (tuple) evaluation in the sub-expression (here Name): > > case ets:select(my_table, [{ > {Name, '$2', '$3', '$4', '_', '_'}, > [], > [{{const, Name}, '$2', '$3', '$4'}] > }]) > > I assume there aren't nested tuples in Name, but just using {Name} like > above would only prevent the outmost tuple from being interpreted as a > "function" or variable. The 'const' expression is much safer here, since > it just says: "include as is". See the ms_transform manpage for details. > > Jacob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ostinelli@REDACTED Fri Jan 10 17:24:18 2020 From: ostinelli@REDACTED (Roberto Ostinelli) Date: Fri, 10 Jan 2020 17:24:18 +0100 Subject: ETS tuple in body In-Reply-To: References: <8659623c-5138-067e-805b-b7d9515c7233@gmx.net> Message-ID: Ok I got it, your example was missing an external tuple: ets:select(my_table, [{ {Name, '$2', '$3', '$4', '_', '_'}, [], [{{{const, Name}, '$2', '$3', '$4'}}] }]). Thank you, r. On Fri, Jan 10, 2020 at 5:17 PM Roberto Ostinelli wrote: > Thank you Jacob, > I already tried a couple of combinations with const but I always got an > error message. For instance: > > (r@REDACTED)2> Name = test. > test > (r@REDACTED)3> ets:select(my_table, [{ > (r@REDACTED)3> {Name, '$2', '$3', '$4', '_', '_'}, > (r@REDACTED)3> [], > (r@REDACTED)3> [{{const, Name}, '$2', '$3', '$4'}] > (r@REDACTED)3> }]). > ** exception error: bad argument > in function ets:select/2 > called as ets:select(my_table, > [{{test,'$2','$3','$4','_','_'}, > [], > [{{const,test},'$2','$3','$4'}]}]) > > > On Fri, Jan 10, 2020 at 5:05 PM Jacob wrote: > >> Hi, >> >> On 1/10/20 4:37 PM, Roberto Ostinelli wrote: >> > MatchBody = case is_tuple(Name) of >> > true -> {{{Name}, '$2', '$3', '$4'}}; >> > _ -> {{Name, '$2', '$3', '$4'}} >> > end, >> > case ets:select(my_table, [{ >> > {Name, '$2', '$3', '$4', '_', '_'}, >> > [], >> > [MatchBody] >> > }]) >> > >> > I need to do this because to make it work for Name values of both test >> > and {test}. >> > Is there a better way? >> >> yes, by using a 'const' expression that will prevent variable substition >> and function (tuple) evaluation in the sub-expression (here Name): >> >> case ets:select(my_table, [{ >> {Name, '$2', '$3', '$4', '_', '_'}, >> [], >> [{{const, Name}, '$2', '$3', '$4'}] >> }]) >> >> I assume there aren't nested tuples in Name, but just using {Name} like >> above would only prevent the outmost tuple from being interpreted as a >> "function" or variable. The 'const' expression is much safer here, since >> it just says: "include as is". See the ms_transform manpage for details. >> >> Jacob >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jacob01@REDACTED Fri Jan 10 18:03:29 2020 From: jacob01@REDACTED (Jacob) Date: Fri, 10 Jan 2020 18:03:29 +0100 Subject: ETS tuple in body In-Reply-To: References: <8659623c-5138-067e-805b-b7d9515c7233@gmx.net> Message-ID: <4c9f860f-d7db-e59e-8fe8-13a410daf9bf@gmx.net> Yep, you're right. I've forgotten to add the enclosing tuple while copying and pasting. Jacob On 1/10/20 5:24 PM, Roberto Ostinelli wrote: > Ok I got it, your example was missing an external tuple: > > ets:select(my_table, [{ > ? ? {Name, '$2', '$3', '$4', '_', '_'}, > ? ? [], > ? ? [{{{const, Name}, '$2', '$3', '$4'}}] > }]). > > Thank you, > r. From alin.popa@REDACTED Fri Jan 10 20:03:57 2020 From: alin.popa@REDACTED (Alin Popa) Date: Fri, 10 Jan 2020 19:03:57 +0000 Subject: High Erlang memory binary Message-ID: Hi all, I've stumbled upon a weird situation (you'll see down below what I mean by weird) where my `system` memory is being quite high, out of which the majority is assigned to `binary`. When I do `:erlang.memory()`, I'm getting back the following values: ``` [ total: 1012506552, processes: 84512344, processes_used: 83993696, system: 927994208, atom: 1845473, atom_used: 1816962, binary: 834439728, code: 48673550, ets: 11823024 ] ``` As you can see, the binary is ~ 89% of the system memory (according to the Erlang doc: "binary The total amount of memory currently allocated for binaries. This memory is part of the memory presented as system memory.") I wrote a function that gives me the memory taken by all processes refc binaries, that looks like this: ``` total = fn -> :erlang.processes() |> Enum.map(fn pid -> try do {_, bins} = :erlang.process_info(pid, :binary) total_size = bins |> Enum.reduce(0, fn {_id, size, _refs}, acc -> size + acc end) {pid, total_size, length(bins)} rescue _ -> {pid, 0, 0} end end) |> Enum.map(fn {pid, total_size, count} -> {pid, total_size, count} end) |> Enum.reduce(0, fn {_pid, total_size, _}, acc -> acc + total_size end) end ``` The result returned by this function is in bytes 9600693, which is ~ 9 MB, and not even near the values of `binary` returned by `:erlang.memory()`. Now, the weird part is that my app is running inside a docker container, and the docker container within a kubernetes cluster. In this setup I can see the problem, but if I'm running it locally, within bare bones docker, I can't see the same issue. And another thing I've noticed, even more weirder, is that when the BEAM starts, the binary memory is ~ 300 MB, and after each request it bumps up till it reaches ~ 900 MB, after which stays constant - what I mean is that the BEAM doesn't crash with out of memory, or something similar, but I'm still worried. Other applications I have, also running on Erlang 22, and exactly the same docker image, don't suffer from this problem, which makes me think this is related to the application code... This is also happening on both Erlang 21, and 22. Another thing to mention is that I used as well `recon`, and after running it, the binary section stays exactly the same, doesn't seem to be a matter of not being garbage collected. My questions are: 1. What other type of binary (beside refc process binaries) can live in that zone of memory? Am I looking for the wrong thing? 2. How can I _look_ at the `binary` memory region to see what I have in there? 3. Any other suggestion on what I might be doing wrong? Any help will be much appreciated. Thanks, Alin -------------- next part -------------- An HTML attachment was scrubbed... URL: From chalor99@REDACTED Mon Jan 13 08:14:45 2020 From: chalor99@REDACTED (Rareman S) Date: Mon, 13 Jan 2020 14:14:45 +0700 Subject: build erlang otp 22.2 but can't used observer In-Reply-To: <2c02d00ac50357ef056aab12aaa44928@smtp.hushmail.com> References: <1adba854-4e7e-5419-f6b2-ad0405e0839e@xbasics.com> <98a39b88748db1fc2c5f3a33e0249d17@smtp.hushmail.com> <2c02d00ac50357ef056aab12aaa44928@smtp.hushmail.com> Message-ID: Hi Alex, Thank you for your support. I'm done with build erlang/otp 19.3 and wxWidgets 3.0.4 on Solaris(11.3)/Sparc platform. Here below wx configure with OTP 19.3 configure for wx 3.0.4 ./configure --with-gtk --with-opengl --disable-optimise --enable-utf8 --enable-stc --enable-compat28 --prefix=/usr/local --enable-debug_info --enable-ipc configure for otp 19.3 on Oracle Developer 12.6 ./configure CC=${IDE_CC} CXX=${IDE_CXX} ???????? ?. 10 ?.?. 2020 ???? 21:30 alex@REDACTED ????????: > If you ran "configure" for wxWidgets as your Ref indicates (with > --disable-share), you didn't compile the shared libraries for Erlang to > use. You need the "--enable-shared" flag instead and place all the > variables right in front of the "configure" command. > > Cheers, > Alex > > On 1/9/20 11:18 PM, Rareman S wrote: > > Hi Alex > Thanks for help. Kerl/asdf need to connected to the internet right? I > cannot direct connect to the internet for some reason. Current I did fixed > some here below. > > checking for wx/stc/stc.h... yes > checking if we can link wxwidgets programs... no > > Above if see previous mail "wx/stc/stc.h... no " i changed gcc from 4.8 > to 4.5. how to link wxwidgets programs? > > **Ref > ./configure CC=/usr/gcc/4.5/bin/gcc CXX=/usr/gcc/4.5/bin/g++ CFLAGS=-fPIC > CXXFLAGS=-fPIC --with-opengl --enable-unicode --enable-graphics_ctx > --enable-gnomeprint --disable-shared --disable-optimise > > ???????? ?. 4 ?.?. 2020 ???? 14:28 alex@REDACTED > ????????: > >> BTW, I should've mentioned also to try using a solution like kerl ( >> https://github.com/kerl/kerl) or maybe asdf ( >> https://github.com/asdf-vm/asdf). That might be of help! >> >> Cheers, >> Alex >> >> On 1/3/20 5:26 PM, alex@REDACTED wrote: >> >> Something to point out is that wxWidgets (wx) version 3.1.3 is a >> development version and in overall you want to stick with stable version >> 3.0.4. Don't remember if Erlang has an issue with 3.1.3, but I know I've >> run into problems with other software that depends on wx. Once you compile >> wx and install it as root (if you didn't use a --prefix location, it should >> install under /usr/local). Thus, wx-config should default to >> /usr/local/bin. Now, it's up to your system config to have those paths >> available. You can run ldconfig from the console/terminal you're using for >> this process or simply reboot to make sure the libraries are made >> available. Note again that you might need to use /etc/ld.so.conf to make >> /usr/local/{lib, lib64} available for dynamic linking. From there on, just >> configure the Erlang as stated. Note that the github version of Erlang >> doesn't bring a configure file with it. You need to run "otp_build >> autoconf" from its base directory first. >> >> Cheers, >> Alex >> >> On 1/2/20 5:04 AM, Rareman S wrote: >> >> Hi, >> >> >> here build wxWidgets-3.1.3 successful I give some output (full in >> attached) and/or configure options below also i tried build simple >> configure option still can't used wx on otp22.2. On solaris didn't have >> ldconfig or ld.so.conf >> Question >> How to put/integrate new wx3.1.3 into otp22? (i just create new symbolic >> link remove the old) >> >> REF >> ./configure --with-opengl --with-gtk=3 --enable-stc --enable-webview >> --enable-shared --enable-compat28 >> wx-config --version >> 3.1.3 >> wx-config --list >> >> Default config is gtk3-unicode-3.1 >> >> Default config in /export/home/itmxadm/WX/wxWidgets-3.1.3 will be used >> for output >> >> Alternate matches: >> gtk2-ansi-3.1 >> gtk2-unicode-3.1 >> wx-config --libs >> -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib -pthreads >> -Wl,-rpath,/export/home/itmxadm/WX/wxWidgets-3.1.3/lib -lwx_gtk3u_xrc-3.1 >> -lwx_gtk3u_html-3.1 -lwx_gtk3u_qa-3.1 -lwx_gtk3u_core-3.1 >> -lwx_baseu_xml-3.1 -lwx_baseu_net-3.1 -lwx_baseu-3.1 >> >> /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o >> richtextdll_richtextstyledlg.o -D__WXGTK__ -DWXBUILDING >> -I./src/regex -DWXUSINGDLL -DWXMAKINGDLL_RICHTEXT -fPIC -DPIC -Wall >> -Wundef -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual >> -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=64 >> -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 >> -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >> -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 >> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz >> -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem >> /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT -O2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/freetype2 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz >> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT >> -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_PTHREADS >> -D_POSIX_PTHREAD_SEMANTICS -I/usr/include/gtk-3.0/unix-print >> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 >> -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ >> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include >> -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 >> -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz >> -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden >> -fvisibility-inlines-hidden ./src/richtext/richtextstyledlg.cpp >> /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o >> richtextdll_richtextstyles.o -D__WXGTK__ -DWXBUILDING >> -I./src/regex -DWXUSINGDLL -DWXMAKINGDLL_RICHTEXT -fPIC -DPIC -Wall >> -Wundef -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual >> -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=64 >> -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 >> -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >> -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 >> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz >> -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem >> /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT -O2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/freetype2 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz >> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT >> -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_PTHREADS >> -D_POSIX_PTHREAD_SEMANTICS -I/usr/include/gtk-3.0/unix-print >> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 >> -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ >> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include >> -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 >> -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz >> -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden >> -fvisibility-inlines-hidden ./src/richtext/richtextstyles.cpp >> /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o >> richtextdll_richtextsymboldlg.o -D__WXGTK__ -DWXBUILDING >> -I./src/regex -DWXUSINGDLL -DWXMAKINGDLL_RICHTEXT -fPIC -DPIC -Wall >> -Wundef -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual >> -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=64 >> -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 >> -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >> -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 >> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz >> -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem >> /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT -O2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/freetype2 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz >> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT >> -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_PTHREADS >> -D_POSIX_PTHREAD_SEMANTICS -I/usr/include/gtk-3.0/unix-print >> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 >> -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ >> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include >> -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 >> -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz >> -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden >> -fvisibility-inlines-hidden ./src/richtext/richtextsymboldlg.cpp >> /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o >> richtextdll_richtextxml.o -D__WXGTK__ -DWXBUILDING -I./src/regex >> -DWXUSINGDLL -DWXMAKINGDLL_RICHTEXT -fPIC -DPIC -Wall -Wundef >> -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual >> -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=64 >> -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 >> -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >> -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 >> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz >> -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem >> /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT -O2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/freetype2 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz >> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT >> -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_PTHREADS >> -D_POSIX_PTHREAD_SEMANTICS -I/usr/include/gtk-3.0/unix-print >> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 >> -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ >> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include >> -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 >> -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz >> -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden >> -fvisibility-inlines-hidden ./src/richtext/richtextxml.cpp >> /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o >> richtextdll_xh_richtext.o -D__WXGTK__ -DWXBUILDING -I./src/regex >> -DWXUSINGDLL -DWXMAKINGDLL_RICHTEXT -fPIC -DPIC -Wall -Wundef >> -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual >> -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=64 >> -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 >> -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >> -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 >> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz >> -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem >> /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT -O2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/freetype2 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz >> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT >> -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_PTHREADS >> -D_POSIX_PTHREAD_SEMANTICS -I/usr/include/gtk-3.0/unix-print >> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 >> -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ >> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include >> -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 >> -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz >> -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden >> -fvisibility-inlines-hidden ./src/xrc/xh_richtext.cpp >> g++ -shared -fPIC -o >> /export/home/itmxadm/WX/wxWidgets-3.1.3/lib/libwx_gtk3u_richtext-3.1.so.3 >> richtextdll_richtextbuffer.o richtextdll_richtextctrl.o >> richtextdll_richtextformatdlg.o richtextdll_richtexthtml.o >> richtextdll_richtextimagedlg.o richtextdll_richtextprint.o >> richtextdll_richtextstyledlg.o richtextdll_richtextstyles.o >> richtextdll_richtextsymboldlg.o richtextdll_richtextxml.o >> richtextdll_xh_richtext.o -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib >> -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib >> -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib >> -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib >> -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib -h >> libwx_gtk3u_richtext-3.1.so.3 -pthreads -lgtk-3 -lgdk-3 -latk-1.0 >> -lgio-2.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo-gobject -lpango-1.0 >> -lcairo -lgobject-2.0 -lgthread-2.0 -lpthread -lglib-2.0 -lX11 -lXxf86vm >> -lSM -lgtk-3 -lgdk-3 -latk-1.0 -lgio-2.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 >> -lcairo-gobject -lpango-1.0 -lcairo -lgobject-2.0 -lglib-2.0 -lXtst >> -lpangoft2-1.0 -lpango-1.0 -lfontconfig -lgobject-2.0 -lglib-2.0 -lfreetype >> -lpng -lz -ljpeg -ltiff -llzma -lwxregexu-3.1 -pthreads -lz -lnsl >> -lsocket -llzma -lm -lwx_gtk3u_html-3.1 -lwx_baseu_xml-3.1 >> -lwx_gtk3u_core-3.1 -lwx_baseu-3.1 -lz -lnsl -lsocket -llzma -lm >> (cd /export/home/itmxadm/WX/wxWidgets-3.1.3/lib/; rm -f >> libwx_gtk3u_richtext-3.1.so; ln -s libwx_gtk3u_richtext-3.1.so.3 >> libwx_gtk3u_richtext-3.1.so) >> /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o stcdll_stc.o >> -D__WXGTK__ -DWXBUILDING -I./src/regex >> -I./src/stc/scintilla/include -I./src/stc/scintilla/lexlib >> -I./src/stc/scintilla/src -D__WX__ -DSCI_LEXER -DNO_CXX11_REGEX >> -DLINK_LEXERS -DWXUSINGDLL -DWXMAKINGDLL_STC -fPIC -DPIC -Wall -Wundef >> -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual >> -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=64 >> -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 >> -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >> -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 >> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz >> -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem >> /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT -O2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/freetype2 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz >> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT >> -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_PTHREADS >> -D_POSIX_PTHREAD_SEMANTICS -I/usr/include/gtk-3.0/unix-print >> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 >> -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ >> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include >> -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 >> -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz >> -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden >> -fvisibility-inlines-hidden ./src/stc/stc.cpp >> /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o stcdll_PlatWX.o >> -D__WXGTK__ -DWXBUILDING -I./src/regex >> -I./src/stc/scintilla/include -I./src/stc/scintilla/lexlib >> -I./src/stc/scintilla/src -D__WX__ -DSCI_LEXER -DNO_CXX11_REGEX >> -DLINK_LEXERS -DWXUSINGDLL -DWXMAKINGDLL_STC -fPIC -DPIC -Wall -Wundef >> -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual >> -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=64 >> -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 >> -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >> -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 >> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz >> -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem >> /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT -O2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/freetype2 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz >> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT >> -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_PTHREADS >> -D_POSIX_PTHREAD_SEMANTICS -I/usr/include/gtk-3.0/unix-print >> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 >> -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ >> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include >> -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 >> -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz >> -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden >> -fvisibility-inlines-hidden ./src/stc/PlatWX.cpp >> /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o >> stcdll_ScintillaWX.o -D__WXGTK__ -DWXBUILDING -I./src/regex >> -I./src/stc/scintilla/include -I./src/stc/scintilla/lexlib >> -I./src/stc/scintilla/src -D__WX__ -DSCI_LEXER -DNO_CXX11_REGEX >> -DLINK_LEXERS -DWXUSINGDLL -DWXMAKINGDLL_STC -fPIC -DPIC -Wall -Wundef >> -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual >> -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=64 >> -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 >> -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >> -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 >> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz >> -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem >> /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT -O2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/freetype2 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz >> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT >> -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_PTHREADS >> -D_POSIX_PTHREAD_SEMANTICS -I/usr/include/gtk-3.0/unix-print >> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 >> -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ >> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include >> -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 >> -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz >> -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden >> -fvisibility-inlines-hidden ./src/stc/ScintillaWX.cpp >> g++ -shared -fPIC -o >> /export/home/itmxadm/WX/wxWidgets-3.1.3/lib/libwx_gtk3u_stc-3.1.so.3 >> stcdll_stc.o stcdll_PlatWX.o stcdll_ScintillaWX.o >> -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib >> -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib >> -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib >> -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib -h >> libwx_gtk3u_stc-3.1.so.3 -pthreads -lgtk-3 -lgdk-3 -latk-1.0 >> -lgio-2.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo-gobject -lpango-1.0 >> -lcairo -lgobject-2.0 -lgthread-2.0 -lpthread -lglib-2.0 -lX11 -lXxf86vm >> -lSM -lgtk-3 -lgdk-3 -latk-1.0 -lgio-2.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 >> -lcairo-gobject -lpango-1.0 -lcairo -lgobject-2.0 -lglib-2.0 -lXtst >> -lpangoft2-1.0 -lpango-1.0 -lfontconfig -lgobject-2.0 -lglib-2.0 -lfreetype >> -lpng -lz -ljpeg -ltiff -llzma -lwxregexu-3.1 -pthreads -lz -lnsl >> -lsocket -llzma -lm -lwxscintilla-3.1 -lwx_gtk3u_core-3.1 -lwx_baseu-3.1 >> -lz -lnsl -lsocket -llzma -lm >> (cd /export/home/itmxadm/WX/wxWidgets-3.1.3/lib/; rm -f >> libwx_gtk3u_stc-3.1.so; ln -s libwx_gtk3u_stc-3.1.so.3 >> libwx_gtk3u_stc-3.1.so) >> /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o gldll_glcmn.o >> -D__WXGTK__ -DWXBUILDING -I./src/regex -DWXUSINGDLL >> -DWXMAKINGDLL_GL -fPIC -DPIC -Wall -Wundef -Wunused-parameter >> -Wno-ctor-dtor-privacy -Woverloaded-virtual -Wno-deprecated-declarations >> -D_FILE_OFFSET_BITS=64 >> -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 >> -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >> -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 >> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz >> -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem >> /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT -O2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/freetype2 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz >> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT >> -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_PTHREADS >> -D_POSIX_PTHREAD_SEMANTICS -I/usr/include/gtk-3.0/unix-print >> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 >> -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ >> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include >> -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 >> -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz >> -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden >> -fvisibility-inlines-hidden ./src/common/glcmn.cpp >> /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o gldll_glx11.o >> -D__WXGTK__ -DWXBUILDING -I./src/regex -DWXUSINGDLL >> -DWXMAKINGDLL_GL -fPIC -DPIC -Wall -Wundef -Wunused-parameter >> -Wno-ctor-dtor-privacy -Woverloaded-virtual -Wno-deprecated-declarations >> -D_FILE_OFFSET_BITS=64 >> -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 >> -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >> -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 >> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz >> -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem >> /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT -O2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/freetype2 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz >> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT >> -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_PTHREADS >> -D_POSIX_PTHREAD_SEMANTICS -I/usr/include/gtk-3.0/unix-print >> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 >> -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ >> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include >> -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 >> -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz >> -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden >> -fvisibility-inlines-hidden ./src/unix/glx11.cpp >> /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o >> gldll_gtk_glcanvas.o -D__WXGTK__ -DWXBUILDING -I./src/regex >> -DWXUSINGDLL -DWXMAKINGDLL_GL -fPIC -DPIC -Wall -Wundef -Wunused-parameter >> -Wno-ctor-dtor-privacy -Woverloaded-virtual -Wno-deprecated-declarations >> -D_FILE_OFFSET_BITS=64 >> -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 >> -I./include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >> -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 >> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz >> -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem >> /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT -O2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/freetype2 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz >> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT >> -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_PTHREADS >> -D_POSIX_PTHREAD_SEMANTICS -I/usr/include/gtk-3.0/unix-print >> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 >> -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ >> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include >> -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 >> -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz >> -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden >> -fvisibility-inlines-hidden ./src/gtk/glcanvas.cpp >> g++ -shared -fPIC -o >> /export/home/itmxadm/WX/wxWidgets-3.1.3/lib/libwx_gtk3u_gl-3.1.so.3 >> gldll_glcmn.o gldll_glx11.o gldll_gtk_glcanvas.o >> -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib -h libwx_gtk3u_gl-3.1.so.3 >> -pthreads -lgtk-3 -lgdk-3 -latk-1.0 -lgio-2.0 -lpangocairo-1.0 >> -lgdk_pixbuf-2.0 -lcairo-gobject -lpango-1.0 -lcairo -lgobject-2.0 >> -lgthread-2.0 -lpthread -lglib-2.0 -lX11 -lXxf86vm -lSM -lgtk-3 -lgdk-3 >> -latk-1.0 -lgio-2.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo-gobject >> -lpango-1.0 -lcairo -lgobject-2.0 -lglib-2.0 -lXtst -lpangoft2-1.0 >> -lpango-1.0 -lfontconfig -lgobject-2.0 -lglib-2.0 -lfreetype -lpng -lz >> -ljpeg -ltiff -llzma -lwxregexu-3.1 -pthreads -lz -lnsl -lsocket >> -llzma -lm -lwx_gtk3u_core-3.1 -lwx_baseu-3.1 -lGL -lGLU -lz -lnsl >> -lsocket -llzma -lm >> (cd /export/home/itmxadm/WX/wxWidgets-3.1.3/lib/; rm -f >> libwx_gtk3u_gl-3.1.so; ln -s libwx_gtk3u_gl-3.1.so.3 >> libwx_gtk3u_gl-3.1.so) >> (if test -f utils/wxrc/Makefile ; then cd utils/wxrc && /usr/bin/gmake >> all ; fi) >> gmake[1]: Entering directory >> `/export/home/itmxadm/WX/wxWidgets-3.1.3/utils/wxrc' >> /export/home/itmxadm/WX/wxWidgets-3.1.3/bk-deps g++ -c -o wxrc_wxrc.o >> -D__WXGTK__ -I. -DWXUSINGDLL -DwxUSE_GUI=0 -Wall -Wundef >> -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual >> -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=64 >> -I/export/home/itmxadm/WX/wxWidgets-3.1.3/lib/wx/include/gtk3-unicode-3.1 >> -I../../include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS >> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 >> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 >> -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 >> -I/usr/lib/glib-2.0/include -I/usr/include/at-spi-2.0 >> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz >> -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -isystem >> /usr/openwin/include -I/usr/openwin/include -pthreads -D_REENTRANT -O2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/freetype2 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz >> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT >> -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_PTHREADS >> -D_POSIX_PTHREAD_SEMANTICS -I/usr/include/gtk-3.0/unix-print >> -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 -I/usr/include/cairo >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 >> -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ >> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include >> -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 >> -I/usr/lib/dbus-1.0/include -I/usr/include/harfbuzz >> -I/usr/include/freetype2 >> -I/scratch/Xbuild/s11.3-sru/x-s11.3-sru-sparc/proto/root_sparc/usr/include/freetype2 >> -I/usr/include/pixman-1 -I/usr/include/libpng14 -fvisibility=hidden >> -fvisibility-inlines-hidden ./wxrc.cpp >> g++ -o wxrc wxrc_wxrc.o -L/export/home/itmxadm/WX/wxWidgets-3.1.3/lib >> -pthreads -lwx_baseu_xml-3.1 -lexpat -lwx_baseu-3.1 -lwxregexu-3.1 >> -pthreads -lz -lnsl -lsocket -llzma -lm -lz -lnsl -lsocket -llzma -lm >> gmake[1]: Leaving directory >> `/export/home/itmxadm/WX/wxWidgets-3.1.3/utils/wxrc' >> >> >> >> ???????? ?. 31 ?.?. 2019 ???? 04:33 alex@REDACTED >> ????????: >> >>> Oops, disregard the $wk, $stl and $st variable calls. Sorry, but I'm >>> half awake, half sleep. Actually "st" is for enabling shared library, >>> which is needed. See below... >>> >>> On 12/30/19 4:24 PM, alex@REDACTED wrote: >>> >>> Yeah, looks like it cannot find the wx shared libraries. Verify the >>> location of the wx files. You might need to configure /etc/ld.so.conf to >>> identify where they are located. For reference, I personally compile >>> wxWidgets from scratch with GTK3 and Mesa already installed with... >>> >>> export CFLAGS="-O3 -fPIC -march=native -pipe" >>> export CXXFLAGS="$CFLAGS" >>> >>> CFLAGS CXXFLAGS ./configure \ >>> --prefix=/usr \ >>> --libdir=/usr/lib64 \ >>> --sysconfdir=/etc \ >>> --enable-mediactrl \ >>> --with-opengl \ >>> --enable-graphics_ctx \ >>> --with-gtk=3 \ >>> --enable-unicode \ >>> --enable-compat28 \ >>> --enable-plugins \ >>> --enable-stc \ >>> --enable-webview \ >>> >>> --enable-shared >>> >>> >>> BTW, the configuration I use to compile Erlang is... >>> >>> CFLAGS ./configure \ >>> --prefix=/usr \ >>> --libdir=/usr/lib64 \ >>> --without-odbc \ >>> --without-megaco \ >>> --enable-threads \ >>> --enable-dirty-schedulers \ >>> --enable-smp-support \ >>> --enable-hipe >>> >>> ...follow by make and make install. These are part of bigger scripts I >>> use to make packages for my Linux distro, but this is practically it. >>> >>> Cheers, >>> Alex >>> >>> On 12/30/19 11:48 AM, Mikael Pettersson wrote: >>> >>> On Mon, Dec 30, 2019 at 4:48 PM Rareman S wrote: >>> >>> Hi, >>> >>> Here is my pre-build with erlang OTP22.2. >>> >>> ... >>> >>> === Running configure in /export/home/itmxadm/otp-OTP-22.2/lib/wx === >>> >>> ... >>> >>> checking if we can link wxwidgets programs... no >>> configure: creating sparc-sun-solaris2.11/config.status >>> config.status: creating config.mk >>> config.status: creating c_src/Makefile >>> configure: WARNING: Can not find wx/stc/stc.h -Wall -fPIC -O -Wno-deprecated-declarations -fomit-frame-pointer -fno-strict-aliasing -D_GNU_SOURCE -D_THREAD_SAFE -D_REENTRANT -I/export/home/itmxadm/WX/wxWidgets-3.1.3/build_x11/lib/wx/include/x11univ-unicode-3.1 -I/export/home/itmxadm/WX/wxWidgets-3.1.3/include -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXUNIVERSAL__ -D__WXX11__ -pthreads -D_REENTRANT >>> configure: WARNING: Can not link wx program are all developer packages installed? >>> >>> ... >>> >>> wx : wxWidgets don't have gl support, wx will NOT be useable >>> wxWidgets don't have wxStyledTextControl (stc.h), wx will NOT be useable >>> Can not link the wx driver, wx will NOT be useable >>> >>> ... >>> >>> ./configure CC=${IDE_CC} CXX=${IDE_CXX} CFLAGS="-O" CXXFLAGS=-g --enable-compat28 --prefix=/usr/local. Above config above after build successful can't used wx. >>> >>> Given the wx-related warnings above, it's not surprising that wx >>> doesn't work for you. You'll need to inspect the config.log file for >>> lib/wx/ so see what the errors were, but off-hand it looks like an >>> incomplete wxWidgets installation. >>> >>> >>> >>> >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From otp@REDACTED Mon Jan 13 11:36:31 2020 From: otp@REDACTED (Erlang/OTP) Date: Mon, 13 Jan 2020 11:36:31 +0100 (CET) Subject: Patch Package OTP 22.2.2 Released Message-ID: <20200113103631.8A3AE254630@hel.cslab.ericsson.net> Patch Package: OTP 22.2.2 Git Tag: OTP-22.2.2 Date: 2020-01-13 Trouble Report Id: OTP-16333, OTP-16371, OTP-16373, OTP-16375, OTP-16376, OTP-16378, OTP-16379 Seq num: ERL-1104, ERL-1125 System: OTP Release: 22 Application: crypto-4.6.4, erts-10.6.2, ssh-4.8.2, stdlib-3.11.1 Predecessor: OTP 22.2.1 Check out the git tag OTP-22.2.2, and build a full OTP system including documentation. Apply one or more applications from this build as patches to your installation using the 'otp_patch_apply' tool. For information on install requirements, see descriptions for each application version below. --------------------------------------------------------------------- --- crypto-4.6.4 ---------------------------------------------------- --------------------------------------------------------------------- The crypto-4.6.4 application can be applied independently of other applications on a full OTP 22 installation. --- Fixed Bugs and Malfunctions --- OTP-16376 Application(s): crypto, ssh Constant time comparisons added. Full runtime dependencies of crypto-4.6.4: erts-9.0, kernel-5.3, stdlib-3.4 --------------------------------------------------------------------- --- erts-10.6.2 ----------------------------------------------------- --------------------------------------------------------------------- Note! The erts-10.6.2 application *cannot* be applied independently of other applications on an arbitrary OTP 22 installation. On a full OTP 22 installation, also the following runtime dependency has to be satisfied: -- kernel-6.5.1 (first satisfied in OTP 22.2) --- Fixed Bugs and Malfunctions --- OTP-16371 Application(s): erts Taking a scheduler offline could cause timers set while executing on that scheduler to be delayed until the scheduler was put online again. This bug was introduced in ERTS version 10.0 (OTP 21.0). OTP-16378 Application(s): erts, stdlib Related Id(s): ERL-1125 The ets:update_counter/4 core dumped when given an ordered_set with write_concurrency enabled and an invalid position. This bug has been fixed. OTP-16379 Application(s): erts A process calling erlang:system_flag(multi_scheduling, block) could end up blocked waiting for the operation to complete indefinitely. --- Improvements and New Features --- OTP-16333 Application(s): erts Related Id(s): ERL-1104 Duplicate entries for [socket:]getopt and [socket:]setopt in man page. Full runtime dependencies of erts-10.6.2: kernel-6.5.1, sasl-3.3, stdlib-3.5 --------------------------------------------------------------------- --- ssh-4.8.2 ------------------------------------------------------- --------------------------------------------------------------------- Note! The ssh-4.8.2 application *cannot* be applied independently of other applications on an arbitrary OTP 22 installation. On a full OTP 22 installation, also the following runtime dependency has to be satisfied: -- crypto-4.6.4 (first satisfied in OTP 22.2.2) --- Fixed Bugs and Malfunctions --- OTP-16373 Application(s): ssh Fixed that ssh_connection:send could allocate a large amount of memory if given an iolist() as input data. OTP-16375 Application(s): ssh Safe atom conversions. OTP-16376 Application(s): crypto, ssh Constant time comparisons added. Full runtime dependencies of ssh-4.8.2: crypto-4.6.4, erts-9.0, kernel-5.3, public_key-1.6.1, stdlib-3.4.1 --------------------------------------------------------------------- --- stdlib-3.11.1 --------------------------------------------------- --------------------------------------------------------------------- Note! The stdlib-3.11.1 application *cannot* be applied independently of other applications on an arbitrary OTP 22 installation. On a full OTP 22 installation, also the following runtime dependency has to be satisfied: -- erts-10.6.2 (first satisfied in OTP 22.2.2) --- Fixed Bugs and Malfunctions --- OTP-16378 Application(s): erts, stdlib Related Id(s): ERL-1125 The ets:update_counter/4 core dumped when given an ordered_set with write_concurrency enabled and an invalid position. This bug has been fixed. Full runtime dependencies of stdlib-3.11.1: compiler-5.0, crypto-3.3, erts-10.6.2, kernel-6.0, sasl-3.0 --------------------------------------------------------------------- --------------------------------------------------------------------- --------------------------------------------------------------------- From micael.karlberg@REDACTED Mon Jan 13 15:55:05 2020 From: micael.karlberg@REDACTED (Micael Karlberg) Date: Mon, 13 Jan 2020 15:55:05 +0100 Subject: New Socket module examples In-Reply-To: References: Message-ID: On 2019-12-23 16:51, Frank Muller wrote: > Hi guys > > I?m playing with the new socket module: > https://erlang.org/doc/man/socket.html > > > The idea is to switch my gen_tcp based Web server to socket. > Currently, I?m using {active, N} and would like to know if anything equivalent is possible with socket? > > Are there any examples I can look at? Not exactly what you are asking for but: https://erlang.org/pipermail/erlang-questions/2019-October/098655.html > > Also, I read somewhere that in R23, gen_tcp will be based on the new socket module. Is this still true? gen_tcp should *work* with the new 'socket' API. That is, if you specify that you want to use the new 'socket', then a socket based on 'socket' will be created. Something like: {ok, Sock} = gen_tcp:connect(Host, Port, [new|Opts]). > > /Frank Regards, /BMK From ludovic@REDACTED Mon Jan 13 12:56:21 2020 From: ludovic@REDACTED (=?utf-8?q?ludovic=40demblans=2Ecom?=) Date: Mon, 13 Jan 2020 12:56:21 +0100 Subject: Custom timer module Message-ID: <3591-5e1c5b00-83-124168a0@122384099> Hello, I'm looking for advice about implementing a timer queue in erlang or elixir. Basically what I need is a queue where I can write a timestamp, a key, and a value. When the local time reaches the timestamp, I want to handle the key/value (I guess receiving a message with the key and fetch, or receiving the key/value). The timer must be cancelable as the value is very small but will lead to heavy computation. I want to be able to fetch a key from outside of the process at any time and run the computation (and then cancel the scheduled computation). This is a subset of the `timer` module. But I need to persist the data to disk and reload on application start. I will have a tiny amount of entries : around 1000. At the moment I have an ordered_set with `{Timestamp, UserKey} = Key` as keys, I lookup for the first key and send_after to self the `Key` with `erlang:start_timer(max(TimeStamp, 1), self(), {run_deletion, Key})`, which returns a ref that I keep in state so I can ignore timer messages with an older ref. Everything is done inside a gen_server where I load the table from disk after init. Also I have to write the table to disk after each update because it is very important that all events are handled. I'm about to implement cancellation but the code becomes messy as I do both table management and data management in the same module. I wonder if there are implementations of this pattern in the community ? I could use a priority queue, but it seems to me that the implementations use a fixed list of priorities, and not arbitrary priorities (like a timestamp). Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From sperber@REDACTED Mon Jan 13 15:29:08 2020 From: sperber@REDACTED (Michael Sperber) Date: Mon, 13 Jan 2020 15:29:08 +0100 Subject: 2nd Call for Participation: BOB 2020 (February 28, Berlin, early-bird until Jan 20) Message-ID: ================================================================================ BOB 2020 Conference ?What happens if we simply use what?s best?? February 28, 2020, Berlin http://bobkonf.de/2020/ Program: http://bobkonf.de/2020/en/program.html Registration: http://bobkonf.de/2020/en/registration.html ================================================================================ BOB is the conference for developers, architects and decision-makers to explore technologies beyond the mainstream in software development, and to find the best tools available to software developers today. Our goal is for all participants of BOB to return home with new insights that enable them to improve their own software development experiences. The program features 14 talks and 8 tutorials on current topics: http://bobkonf.de/2020/en/program.html The subject range of talks includes functional programming, formal methods, architecture documentation, functional-reactive programming, and language design. The tutorials feature introductions to Idris, Haskell, F#, TLA+, ReasonML, and probabilistic programming. Heather Miller will give the keynote talk. Registration is open online: http://bobkonf.de/2020/en/registration.html NOTE: The early-bird rates expire on January 20, 2020! BOB cooperates with the Racketfest conference on the day before BOB: https://racketfest.com/ BOB cooperates with the :clojureD conference on the day after BOB: https://clojured.de/ From ulf@REDACTED Mon Jan 13 17:14:00 2020 From: ulf@REDACTED (Ulf Wiger) Date: Mon, 13 Jan 2020 17:14:00 +0100 Subject: Custom timer module In-Reply-To: <3591-5e1c5b00-83-124168a0@122384099> References: <3591-5e1c5b00-83-124168a0@122384099> Message-ID: FWIW, the KVDB project [1] implemented both priority queues and timers (which quite flexible scheduling options), with persistence. Example, from an Erlang Factory presentation 2013 [2]: 12> kvdb_cron:create_crontab(db, timers). ok 13> kvdb_cron:add( db,timers,"{in 3 secs; 3 times}",[],kvdb_cron,testf,[]). {ok,{q_key,<<>>,105729091563262,105729094536167}} 14> CRON!! {{{2013,3,19},{21,38,14}},658320} CRON!! {{{2013,3,19},{21,38,17}},655700} CRON!! {{{2013,3,19},{21,38,20}},642523} I haven't touched the code in a long time, but if there is sufficient interest, I could be persuaded to lend support. :) BR, Ulf W [1] https://github.com/Feuerlabs/kvdb [2] http://www.erlang-factory.com/conference/SFBay2013/speakers/UlfWiger Den m?n 13 jan. 2020 kl 16:33 skrev ludovic@REDACTED < ludovic@REDACTED>: > Hello, > > I'm looking for advice about implementing a timer queue in erlang or > elixir. > > Basically what I need is a queue where I can write a timestamp, a key, and > a value. When the local time reaches the timestamp, I want to handle the > key/value (I guess receiving a message with the key and fetch, or receiving > the key/value). > The timer must be cancelable as the value is very small but will lead to > heavy computation. I want to be able to fetch a key from outside of the > process at any time and run the computation (and then cancel the scheduled > computation). > > This is a subset of the `timer` module. But I need to persist the data to > disk and reload on application start. > > I will have a tiny amount of entries : around 1000. > > At the moment I have an ordered_set with `{Timestamp, UserKey} = Key` as > keys, I lookup for the first key and send_after to self the `Key` with > `erlang:start_timer(max(TimeStamp, 1), self(), {run_deletion, Key})`, > which returns a ref that I keep in state so I can ignore timer messages > with an older ref. Everything is done inside a gen_server where I load the > table from disk after init. Also I have to write the table to disk after > each update because it is very important that all events are handled. > > I'm about to implement cancellation but the code becomes messy as I do > both table management and data management in the same module. > > I wonder if there are implementations of this pattern in the community ? I > could use a priority queue, but it seems to me that the implementations use > a fixed list of priorities, and not arbitrary priorities (like a timestamp). > > Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From ludovic@REDACTED Mon Jan 13 18:52:15 2020 From: ludovic@REDACTED (=?utf-8?q?ludovic=40demblans=2Ecom?=) Date: Mon, 13 Jan 2020 18:52:15 +0100 Subject: =?utf-8?q?Re=3A?= Custom timer module In-Reply-To: Message-ID: <10b1-5e1cae80-1d-6f867c80@208653485> Hi Ulf, thank you very much. I'm not sure I want to add a full application as a dependency at this time but I will definitely look at the code, this will be a good read ! -- lud Le Lundi, Janvier 13, 2020 17:14 CET, Ulf Wiger a ?crit: ?FWIW, the KVDB project [1] implemented both priority queues and timers (which quite flexible scheduling options), with persistence.?Example, from an Erlang Factory presentation 2013 [2]:?12> kvdb_cron:create_crontab(db, timers).ok13> kvdb_cron:add( db,timers,"{in 3 secs; 3 times}",[],kvdb_cron,testf,[]).{ok,{q_key,<<>>,105729091563262,105729094536167}}14>CRON!! {{{2013,3,19},{21,38,14}},658320}CRON!! {{{2013,3,19},{21,38,17}},655700}CRON!! {{{2013,3,19},{21,38,20}},642523}?I haven't touched the code in a long time, but if there is sufficient interest, I could be persuaded to lend support. :)?BR,Ulf W?[1] https://github.com/Feuerlabs/kvdb[2]?http://www.erlang-factory.com/conference/SFBay2013/speakers/UlfWiger -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukas@REDACTED Tue Jan 14 08:55:27 2020 From: lukas@REDACTED (Lukas Larsson) Date: Tue, 14 Jan 2020 08:55:27 +0100 Subject: High Erlang memory binary In-Reply-To: References: Message-ID: On Fri, Jan 10, 2020 at 8:04 PM Alin Popa wrote: > Hi all, > Hello! > > I've stumbled upon a weird situation (you'll see down below what I mean by > weird) where my `system` memory is being quite high, out of which the > majority is assigned to `binary`. > When I do `:erlang.memory()`, I'm getting back the following values: > ``` > [ > total: 1012506552, > processes: 84512344, > processes_used: 83993696, > system: 927994208, > atom: 1845473, > atom_used: 1816962, > binary: 834439728, > code: 48673550, > ets: 11823024 > ] > ``` > As you can see, the binary is ~ 89% of the system memory (according to the > Erlang doc: > "binary > The total amount of memory currently allocated for binaries. This memory > is part of the memory presented as system memory.") > > I wrote a function that gives me the memory taken by all processes refc > binaries, that looks like this: > ``` > total = fn -> > :erlang.processes() > |> Enum.map(fn pid -> > try do > {_, bins} = :erlang.process_info(pid, :binary) > total_size = bins |> Enum.reduce(0, fn {_id, size, _refs}, acc -> > size + acc end) > {pid, total_size, length(bins)} > rescue > _ -> {pid, 0, 0} > end > end) > |> Enum.map(fn {pid, total_size, count} -> > {pid, total_size, count} > end) > |> Enum.reduce(0, fn {_pid, total_size, _}, acc -> acc + total_size end) > end > ``` > The result returned by this function is in bytes 9600693, which is ~ 9 MB, > and not even near the values of `binary` returned by `:erlang.memory()`. > > Now, the weird part is that my app is running inside a docker container, > and the docker container within a kubernetes cluster. In this setup I can > see the problem, but if I'm running it locally, within bare bones docker, I > can't see the same issue. And another thing I've noticed, even more > weirder, is that when the BEAM starts, the binary memory is ~ 300 MB, and > after each request it bumps up till it reaches ~ 900 MB, after which stays > constant - what I mean is that the BEAM doesn't crash with out of memory, > or something similar, but I'm still worried. Other applications I have, > also running on Erlang 22, and exactly the same docker image, don't suffer > from this problem, which makes me think this is related to the application > code... > This is also happening on both Erlang 21, and 22. > > Another thing to mention is that I used as well `recon`, and after running > it, the binary section stays exactly the same, doesn't seem to be a matter > of not being garbage collected. > > My questions are: > 1. What other type of binary (beside refc process binaries) can live in > that zone of memory? Am I looking for the wrong thing? > The main ones are binaries kept by ets tables and ports. > 2. How can I _look_ at the `binary` memory region to see what I have in > there? > You can use the instrument module in runtime_tools to get some more insights. > 3. Any other suggestion on what I might be doing wrong? > >From what you describe above I would look at the inet ports that are running and make sure that they are closed and that they use sane buffer sizes. > > Any help will be much appreciated. > > Thanks, > Alin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alin.popa@REDACTED Tue Jan 14 13:05:13 2020 From: alin.popa@REDACTED (Alin Popa) Date: Tue, 14 Jan 2020 12:05:13 +0000 Subject: High Erlang memory binary In-Reply-To: References: Message-ID: Thanks so much, Lukas; I'll try to look at the inet ports for now, as I already did some experimentation (i.e. killing some processes), and the memory went down a bit (it goes back up, but this shows me that there may be something around that area. Alin On Tue, Jan 14, 2020 at 7:55 AM Lukas Larsson wrote: > > > On Fri, Jan 10, 2020 at 8:04 PM Alin Popa wrote: > >> Hi all, >> > > Hello! > > >> >> I've stumbled upon a weird situation (you'll see down below what I mean >> by weird) where my `system` memory is being quite high, out of which the >> majority is assigned to `binary`. >> When I do `:erlang.memory()`, I'm getting back the following values: >> ``` >> [ >> total: 1012506552, >> processes: 84512344, >> processes_used: 83993696, >> system: 927994208, >> atom: 1845473, >> atom_used: 1816962, >> binary: 834439728, >> code: 48673550, >> ets: 11823024 >> ] >> ``` >> As you can see, the binary is ~ 89% of the system memory (according to >> the Erlang doc: >> "binary >> The total amount of memory currently allocated for binaries. This memory >> is part of the memory presented as system memory.") >> >> I wrote a function that gives me the memory taken by all processes refc >> binaries, that looks like this: >> ``` >> total = fn -> >> :erlang.processes() >> |> Enum.map(fn pid -> >> try do >> {_, bins} = :erlang.process_info(pid, :binary) >> total_size = bins |> Enum.reduce(0, fn {_id, size, _refs}, acc -> >> size + acc end) >> {pid, total_size, length(bins)} >> rescue >> _ -> {pid, 0, 0} >> end >> end) >> |> Enum.map(fn {pid, total_size, count} -> >> {pid, total_size, count} >> end) >> |> Enum.reduce(0, fn {_pid, total_size, _}, acc -> acc + total_size end) >> end >> ``` >> The result returned by this function is in bytes 9600693, which is ~ 9 >> MB, and not even near the values of `binary` returned by `:erlang.memory()`. >> >> Now, the weird part is that my app is running inside a docker container, >> and the docker container within a kubernetes cluster. In this setup I can >> see the problem, but if I'm running it locally, within bare bones docker, I >> can't see the same issue. And another thing I've noticed, even more >> weirder, is that when the BEAM starts, the binary memory is ~ 300 MB, and >> after each request it bumps up till it reaches ~ 900 MB, after which stays >> constant - what I mean is that the BEAM doesn't crash with out of memory, >> or something similar, but I'm still worried. Other applications I have, >> also running on Erlang 22, and exactly the same docker image, don't suffer >> from this problem, which makes me think this is related to the application >> code... >> This is also happening on both Erlang 21, and 22. >> >> Another thing to mention is that I used as well `recon`, and after >> running it, the binary section stays exactly the same, doesn't seem to be a >> matter of not being garbage collected. >> >> My questions are: >> 1. What other type of binary (beside refc process binaries) can live in >> that zone of memory? Am I looking for the wrong thing? >> > > The main ones are binaries kept by ets tables and ports. > > >> 2. How can I _look_ at the `binary` memory region to see what I have in >> there? >> > > You can use the instrument module in runtime_tools to get some more > insights. > > >> 3. Any other suggestion on what I might be doing wrong? >> > > From what you describe above I would look at the inet ports that are > running and make sure that they are closed and that they use sane buffer > sizes. > >> >> Any help will be much appreciated. >> >> Thanks, >> Alin >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alin.popa@REDACTED Tue Jan 14 13:06:35 2020 From: alin.popa@REDACTED (Alin Popa) Date: Tue, 14 Jan 2020 12:06:35 +0000 Subject: High Erlang memory binary In-Reply-To: References: Message-ID: Thanks Mike, In fact that's a good point, even though I was aware of this, haven't spent much time looking at those things, so will add it to my list. Alin On Tue, Jan 14, 2020 at 11:59 AM Mike Benza wrote: > Alin, > >> >> 3. Any other suggestion on what I might be doing wrong? >> > > I ran into a similar problem a few years ago. I was using jiffy to decode > JSON blobs. Jiffy gave me back sliced binaries from the original binary I > passed in. This kept the whole binary in memory, even if I was just using > a tiny portion of it and discarding the rest. If you're doing this > (unlikely that you've run into the exact same problem), use the > copy_strings option to jiffy. > > If not, consider looking for other cases where you start with a large > binary, discard most of it, and keep a small portion of it. That may be > the cause of your binary bloat. If you find something like that, try > copying the binaries in a way that causes the original binary to be > released from memory. > > - Mike > >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikebenza@REDACTED Tue Jan 14 12:59:38 2020 From: mikebenza@REDACTED (Mike Benza) Date: Tue, 14 Jan 2020 05:59:38 -0600 Subject: High Erlang memory binary In-Reply-To: References: Message-ID: Alin, > > 3. Any other suggestion on what I might be doing wrong? > I ran into a similar problem a few years ago. I was using jiffy to decode JSON blobs. Jiffy gave me back sliced binaries from the original binary I passed in. This kept the whole binary in memory, even if I was just using a tiny portion of it and discarding the rest. If you're doing this (unlikely that you've run into the exact same problem), use the copy_strings option to jiffy. If not, consider looking for other cases where you start with a large binary, discard most of it, and keep a small portion of it. That may be the cause of your binary bloat. If you find something like that, try copying the binaries in a way that causes the original binary to be released from memory. - Mike > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Wed Jan 15 17:40:54 2020 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Wed, 15 Jan 2020 17:40:54 +0100 Subject: Use of spinlocks in Erlang In-Reply-To: References: Message-ID: On Tue, Jan 7, 2020 at 10:01 AM Andreas Schultz < andreas.schultz@REDACTED> wrote: > > Could any of the Erlang gurus or ERTS developers comment on the use of > home grown mutexes and spinlocks in Erlang in light of that discussion? > > Not a locking expert in the ERTS, but: The locking API is there to provide a factoring point for the BEAM. The idea is that we have a locking API to use in ERTS which then maps to different implementations as we see fit. This allows us to target both UNIX, Windows, and embedded OS'es at the same time, with a consistent API. But it gets better than that! We can use the factoring point to "plug in" different locking models and try them out. This allows us to choose a locking model which works well. It also allows us to plug in various debugging/correctness checks at compile time. For instance that lock ordering is preserved, if locks are contended on, or if a deadlock happened. That is, the current locking model is sort-of chosen at compile time, based on the capabilities of the underlying system. All in all, I'm going to claim that the system is not so much "home grown" as it is a sensible wrapper around an underlying system. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.schultz@REDACTED Wed Jan 15 17:54:27 2020 From: andreas.schultz@REDACTED (Andreas Schultz) Date: Wed, 15 Jan 2020 17:54:27 +0100 Subject: Use of spinlocks in Erlang In-Reply-To: References: Message-ID: Am Mi., 15. Jan. 2020 um 17:41 Uhr schrieb Jesper Louis Andersen < jesper.louis.andersen@REDACTED>: > On Tue, Jan 7, 2020 at 10:01 AM Andreas Schultz < > andreas.schultz@REDACTED> wrote: > >> >> Could any of the Erlang gurus or ERTS developers comment on the use of >> home grown mutexes and spinlocks in Erlang in light of that discussion? >> >> > Not a locking expert in the ERTS, but: > > The locking API is there to provide a factoring point for the BEAM. The > idea is that we have a locking API to use in ERTS which then maps to > different implementations as we see fit. This allows us to target both > UNIX, Windows, and embedded OS'es at the same time, with a consistent API. > But it gets better than that! > > We can use the factoring point to "plug in" different locking models and > try them out. This allows us to choose a locking model which works well. It > also allows us to plug in various debugging/correctness checks at compile > time. For instance that lock ordering is preserved, if locks are contended > on, or if a deadlock happened. > > That is, the current locking model is sort-of chosen at compile time, > based on the capabilities of the underlying system. > > All in all, I'm going to claim that the system is not so much "home grown" > as it is a sensible wrapper around an underlying system. > I have seen the different underlying implementations for the locking primitives. There are wrappers for Windows and POSIX threads (pthread). But there also seems to be a completely independent implementation of mutexes and spinlocks that does not use the OS or libc provided primitives. On Linux that Erlang specific implementation appears to be used by default (that is what I called "home grown"). The pthread version is only used when Erlang is build with valgrind support (or so it seems). I was thinking about hacking a build to use only the pthread locking primitives (without the other valdrind overhead) and run some benchmarks. However, my hope was that some Erlang expert could shed some light in the locking before I spent the time to do that. Anyhow, does anybody have a suggestion for an existing benchmark that could demonstrate differences between locking primitives? Andreas > > -- > J. > -- Andreas Schultz -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard@REDACTED Wed Jan 15 23:02:40 2020 From: rickard@REDACTED (Rickard Green) Date: Wed, 15 Jan 2020 23:02:40 +0100 Subject: Use of spinlocks in Erlang In-Reply-To: References: Message-ID: On Wed, Jan 15, 2020 at 5:54 PM Andreas Schultz < andreas.schultz@REDACTED> wrote: > > > > Am Mi., 15. Jan. 2020 um 17:41 Uhr schrieb Jesper Louis Andersen < jesper.louis.andersen@REDACTED>: >> >> On Tue, Jan 7, 2020 at 10:01 AM Andreas Schultz < andreas.schultz@REDACTED> wrote: >>> >>> >>> Could any of the Erlang gurus or ERTS developers comment on the use of home grown mutexes and spinlocks in Erlang in light of that discussion? >>> >> >> Not a locking expert in the ERTS, but: >> >> The locking API is there to provide a factoring point for the BEAM. The idea is that we have a locking API to use in ERTS which then maps to different implementations as we see fit. This allows us to target both UNIX, Windows, and embedded OS'es at the same time, with a consistent API. But it gets better than that! >> >> We can use the factoring point to "plug in" different locking models and try them out. This allows us to choose a locking model which works well. It also allows us to plug in various debugging/correctness checks at compile time. For instance that lock ordering is preserved, if locks are contended on, or if a deadlock happened. >> >> That is, the current locking model is sort-of chosen at compile time, based on the capabilities of the underlying system. >> >> All in all, I'm going to claim that the system is not so much "home grown" as it is a sensible wrapper around an underlying system. > > > I have seen the different underlying implementations for the locking primitives. There are wrappers for Windows and POSIX threads (pthread). But there also seems to be a completely independent implementation of mutexes and spinlocks that does not use the OS or libc provided primitives. > On Linux that Erlang specific implementation appears to be used by default (that is what I called "home grown"). The pthread version is only used when Erlang is build with valgrind support (or so it seems). > > I was thinking about hacking a build to use only the pthread locking primitives (without the other valdrind overhead) and run some benchmarks. > However, my hope was that some Erlang expert could shed some light in the locking before I spent the time to do that. > > Anyhow, does anybody have a suggestion for an existing benchmark that could demonstrate differences between locking primitives? > > Andreas > >> >> >> -- >> J. > > > > -- > > Andreas Schultz There are more or less no pure spinlocks left in the VM (there might be in some test-code and/or at some initialization phase). The last one at a potentially heavily contended place was removed not long ago though < http://erlang.org/download/OTP-22.1.8.README>. We have "homegrown" lock implementations that spin a while trying to acquire a lock that is locked. The spinning since it significantly improve performance. The spinning is bounded though and a thread not successfully acquiring a lock will eventually go to sleep. The two major "homegrown" lock implementations: -- Process locks -- Our process lock implementation is mainly a memory optimization. Each process (currently) have 5 different locks.The 5 locks of a process consumes 6 words in total. When using pthread mutexes 25 words are used (on my linux machine). Our process lock implementation also makes it cheaper to lock/unlock multiple locks of one processes in one operation. The cost of locking all 5 in one operation is the same as locking one of them. -- Rwlocks -- This implementation came about since the NPTL *) rwlocks was not fair. By default a reader preferred approach was used by NPTL rwlocks which easily could (and did) starve writers. You could configure them as writer preferred which was a bit better, but the main problem with starvation still remained (in this case of readers). The performance of the NPTL rwlocks was also quite bad in most scenarios. I write "was" since I don't know if changes has been made since the last time I looked at this. Besides being fair our rwlock implementation also have a reader optimized mode which improve performance in scenarios where you mostly only read-lock the rwlock. This by keeping track of readers in separate cachelines and by this avoiding cacheline ping-ponging. On a big smp machine this improvement can be huge. Such rwlocks are e.g. used when you pass the read_concurrency option to ets tables. *) Native POSIX Thread Library (used on Linux) The NPTL rwlocks was quite a disappointment, but NPTL mutexes was the opposite. The performance was really good. Especially in heavily contended cases. On Linux they are used for all "mutex-cases" except for process locks. Regards, Rickard -- Rickard Green, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From petergi@REDACTED Thu Jan 16 04:09:00 2020 From: petergi@REDACTED (Peter J Etheridge) Date: Thu, 16 Jan 2020 14:09:00 +1100 Subject: dbg:p/2 Message-ID: <38b8cd55788553942d1acdbaf96a959c4e4b8628@webmail.iinet.net.au> dear friends,i am trying to debug a message sent. when i run;dbg:p(registered_name, [m]). {ok, [{matched,new_node@REDACTED,1}]} what is the next step ? thank you in advance.peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From micael.karlberg@REDACTED Thu Jan 16 11:46:40 2020 From: micael.karlberg@REDACTED (Micael Karlberg) Date: Thu, 16 Jan 2020 11:46:40 +0100 Subject: esock_atom_user problem and Android builds In-Reply-To: References: <4c3e4f15-63a5-0cc8-313e-668d632e1068@gmail.com> Message-ID: <5feff8d0-4e27-e51f-a8ae-3cbba80115f5@ericsson.com> A fix has now been merged (into maint and master). On 2020-01-10 13:56, Micael Karlberg wrote: > Hi, > > It seems you are correct. Those kind of atoms are (supposed to be) > created: > > ????GLOBAL_ATOM_DEFS (in socket_int.h) > ????GLOBAL_ATOMS???? (in socket_nif.c) > > Must have missed one :( Actually I missed two (also esock_atom_kernel). > > Regards, > ????/BMK > Regards, /BMK > On 2020-01-09 14:43, Joakim G. wrote: >> Hi, >> I'm trying to cross compile BEAM for Android but I'm stuck on a compile error. >> >> It seems that 'esock_atom_user' is undeclared and I can not even find any decalartion of it on the >> emulator/erts code. >> >> Can anyone point me in the right direction? >> >> Cheers >> /Joakim >> >> jocke@REDACTED:~/src/erlang/otp_src_22.2$ make noboot >> make USE_PGO=false BOOT_PREFIX= build_erl_interface emulator libs local_setup >> ... >> make[4]: G?r till katalogen ?/home/jocke/src/erlang/otp_src_22.2/erts/emulator? >> ??MAKE?? ?opt >> make[5]: G?r till katalogen ?/home/jocke/src/erlang/otp_src_22.2/erts/emulator? >> ??GEN?? ?arm-unknown-linux-androideabi/gen_git_version.mk >> ??CC?? ?obj/arm-unknown-linux-androideabi/opt/smp/socket_util.o >> nifs/common/socket_util.c: In function 'esock_encode_packet_pkttype': >> nifs/common/socket_util.c:1495:21: error: 'esock_atom_user' undeclared (first use in this function) >> ????????? *ePktType = esock_atom_user; >> >> > From jakabac@REDACTED Thu Jan 16 10:40:57 2020 From: jakabac@REDACTED (Jaka Bac) Date: Thu, 16 Jan 2020 10:40:57 +0100 Subject: Use of spinlocks in Erlang In-Reply-To: References: Message-ID: Since this question has popped up, I looked at how the ethread part of locking is written for Windows (as opposed to Linux). The waits here also seem to spin potentially (on both Windows and POSIX implementation) Linux implementation is using futexes while standard Windows events are used on Windows. The question is what is the earliest version of Windows that should be officially supported since starting with Windows 8, there is a mechanism similar to futexes available (and everything which does not have this feature is pretty much EOL'ed from MS now) https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-waitonaddress https://devblogs.microsoft.com/oldnewthing/20170601-00/?p=96265 I know that Windows port of Erlang is not a priority, but would it make sense to update the thread events to use WaitOnAddress/WakeByAddressXXX? Before I do any experiments by myself I would like to know if the Erlang/OTP gurus see a potential gain here. Thanks, Jaka On Wed, 15 Jan 2020 at 23:03, Rickard Green wrote: > On Wed, Jan 15, 2020 at 5:54 PM Andreas Schultz < > andreas.schultz@REDACTED> wrote: > > > > > > > > Am Mi., 15. Jan. 2020 um 17:41 Uhr schrieb Jesper Louis Andersen < > jesper.louis.andersen@REDACTED>: > >> > >> On Tue, Jan 7, 2020 at 10:01 AM Andreas Schultz < > andreas.schultz@REDACTED> wrote: > >>> > >>> > >>> Could any of the Erlang gurus or ERTS developers comment on the use of > home grown mutexes and spinlocks in Erlang in light of that discussion? > >>> > >> > >> Not a locking expert in the ERTS, but: > >> > >> The locking API is there to provide a factoring point for the BEAM. The > idea is that we have a locking API to use in ERTS which then maps to > different implementations as we see fit. This allows us to target both > UNIX, Windows, and embedded OS'es at the same time, with a consistent API. > But it gets better than that! > >> > >> We can use the factoring point to "plug in" different locking models > and try them out. This allows us to choose a locking model which works > well. It also allows us to plug in various debugging/correctness checks at > compile time. For instance that lock ordering is preserved, if locks are > contended on, or if a deadlock happened. > >> > >> That is, the current locking model is sort-of chosen at compile time, > based on the capabilities of the underlying system. > >> > >> All in all, I'm going to claim that the system is not so much "home > grown" as it is a sensible wrapper around an underlying system. > > > > > > I have seen the different underlying implementations for the locking > primitives. There are wrappers for Windows and POSIX threads (pthread). But > there also seems to be a completely independent implementation of mutexes > and spinlocks that does not use the OS or libc provided primitives. > > On Linux that Erlang specific implementation appears to be used by > default (that is what I called "home grown"). The pthread version is only > used when Erlang is build with valgrind support (or so it seems). > > > > I was thinking about hacking a build to use only the pthread locking > primitives (without the other valdrind overhead) and run some benchmarks. > > However, my hope was that some Erlang expert could shed some light in > the locking before I spent the time to do that. > > > > Anyhow, does anybody have a suggestion for an existing benchmark that > could demonstrate differences between locking primitives? > > > > Andreas > > > >> > >> > >> -- > >> J. > > > > > > > > -- > > > > Andreas Schultz > > > There are more or less no pure spinlocks left in the VM (there might be in > some test-code and/or at some initialization phase). The last one at a > potentially heavily contended place was removed not long ago though < > http://erlang.org/download/OTP-22.1.8.README>. > > We have "homegrown" lock implementations that spin a while trying to > acquire a lock that is locked. The spinning since it significantly improve > performance. The spinning is bounded though and a thread not successfully > acquiring a lock will eventually go to sleep. > > The two major "homegrown" lock implementations: > > -- Process locks -- > > Our process lock implementation is mainly a memory optimization. Each > process (currently) have 5 different locks.The 5 locks of a process > consumes 6 words in total. When using pthread mutexes 25 words are used (on > my linux machine). Our process lock implementation also makes it cheaper to > lock/unlock multiple locks of one processes in one operation. The cost of > locking all 5 in one operation is the same as locking one of them. > > -- Rwlocks -- > > This implementation came about since the NPTL *) rwlocks was not fair. By > default a reader preferred approach was used by NPTL rwlocks which easily > could (and did) starve writers. You could configure them as writer > preferred which was a bit better, but the main problem with starvation > still remained (in this case of readers). The performance of the NPTL > rwlocks was also quite bad in most scenarios. I write "was" since I don't > know if changes has been made since the last time I looked at this. > > Besides being fair our rwlock implementation also have a reader optimized > mode which improve performance in scenarios where you mostly only read-lock > the rwlock. This by keeping track of readers in separate cachelines and by > this avoiding cacheline ping-ponging. On a big smp machine this improvement > can be huge. Such rwlocks are e.g. used when you pass the read_concurrency > option to ets tables. > > *) Native POSIX Thread Library (used on Linux) > > > The NPTL rwlocks was quite a disappointment, but NPTL mutexes was the > opposite. The performance was really good. Especially in heavily contended > cases. On Linux they are used for all "mutex-cases" except for process > locks. > > Regards, > Rickard > -- > Rickard Green, Erlang/OTP, Ericsson AB > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ostinelli@REDACTED Fri Jan 17 10:29:18 2020 From: ostinelli@REDACTED (Roberto Ostinelli) Date: Fri, 17 Jan 2020 10:29:18 +0100 Subject: erlang Message-ID: All, What is the proper way to set a custom compression of term_to_binary/2 in a specific send operation, so that I can use it only when I'm sending a larger message (~80MB)? Is this how I should do it, compressing and sending the compressed bytes explicitly? Bin = term_to_binary(Term, [{compressed, 9}]), my_proc ! Bin Thanks, r. -------------- next part -------------- An HTML attachment was scrubbed... URL: From torben.lehoff@REDACTED Fri Jan 17 11:23:54 2020 From: torben.lehoff@REDACTED (Torben Hoffmann) Date: Fri, 17 Jan 2020 11:23:54 +0100 Subject: Using an Erlang LSP server with Sublime Text 3 Message-ID: Hi, I'm trying to get this to work, but I'm running into problems, so I was wondering if others had tried this at any point? I have posted this in the LSP room for ST on Discord, but that room seems pretty dead? Looking in the console for ST3 I find a complaint about Rebar (the ancient one, so I'm ignoring that for now) and a problem wrt reading a config file: Unable to open /Users/torben.hoffmann/Library/Application Support/Sublime Text 3/Packages/LSP/LSP.sublime-settings Which is a bit confusing because that file is at Packages/User/LSP.sublime-settings. This seems to be an LSP problem rather than something to do with the LS I have installed for Erlang. I'm using ST3 3.2.2, 3211 on Mac Mojave. Happy to provide additional information - at this point I don't know what else to provide. I'm using this language server for Erlang: github.com/erlang-ls/erlang_ls But given the nature of the error messages I don't think that is the issue, at least not yet ;-) Cheers, Torben -- http://www.linkedin.com/in/torbenhoffmann @LeHoff -------------- next part -------------- An HTML attachment was scrubbed... URL: From kenneth.lundin@REDACTED Fri Jan 17 12:31:04 2020 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Fri, 17 Jan 2020 12:31:04 +0100 Subject: erlang In-Reply-To: References: Message-ID: Yes , that is the way to do it. You have to create a binary with compressed Erlang External Format first and then send it. /Kenneth -------------- next part -------------- An HTML attachment was scrubbed... URL: From ostinelli@REDACTED Fri Jan 17 13:34:35 2020 From: ostinelli@REDACTED (Roberto Ostinelli) Date: Fri, 17 Jan 2020 13:34:35 +0100 Subject: erlang In-Reply-To: References: Message-ID: Ok, I will do that. Thank you Kenneth, r. On Fri, Jan 17, 2020 at 12:31 PM Kenneth Lundin wrote: > Yes , that is the way to do it. You have to create a binary with > compressed Erlang External Format first and then send it. > > /Kenneth > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dietmar-s@REDACTED Fri Jan 17 11:08:40 2020 From: dietmar-s@REDACTED (Dietmar Schaefer) Date: Fri, 17 Jan 2020 11:08:40 +0100 Subject: how does it work Message-ID: I found this supervisor code: ???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? -define(SERVER,?MODULE).????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? start_link()->??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ? supervisor:start_link({local,?SERVER},?MODULE,[]).??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? init([])->???????????????????? ??? {ok, {{one_for_all, 0, 1},[]}}. How can it work without any specification about what to start? regards Dietmar -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmytro.lytovchenko@REDACTED Fri Jan 17 14:23:11 2020 From: dmytro.lytovchenko@REDACTED (Dmytro Lytovchenko) Date: Fri, 17 Jan 2020 14:23:11 +0100 Subject: how does it work In-Reply-To: References: Message-ID: It starts nothing just empty supervisor. You can add more by using `supervisor:start_child(SupName, Spec)` https://erlang.org/doc/man/supervisor.html#start_child-2 On Fri, 17 Jan 2020 at 13:50, Dietmar Schaefer wrote: > I found this supervisor code: > > > -define(SERVER,?MODULE). > > > > start_link()-> > > supervisor:start_link({local,?SERVER},?MODULE,[]). > > > > init([])-> > > {ok, {{one_for_all, 0, 1},[]}}. > > How can it work without any specification about what to start? > > > regards > > Dietmar > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchesneau@REDACTED Fri Jan 17 16:23:29 2020 From: bchesneau@REDACTED (Benoit Chesneau) Date: Fri, 17 Jan 2020 16:23:29 +0100 Subject: [ann] next Erlang & Elixir paris meetup on Tuesday, 21/01 Message-ID: For speaking people next meetup in Paris will happen on Tuesday 01/21: https://www.meetup.com/Erlang-Paris/events/267270583/ I hope to see you there :) Beno?t -------------- next part -------------- An HTML attachment was scrubbed... URL: From vans_163@REDACTED Fri Jan 17 18:06:55 2020 From: vans_163@REDACTED (Vans S) Date: Fri, 17 Jan 2020 17:06:55 +0000 (UTC) Subject: locked up system using :ets.match_object References: <1519436661.15122799.1579280815081.ref@mail.yahoo.com> Message-ID: <1519436661.15122799.1579280815081@mail.yahoo.com> I am having some performance trouble in a system that does a few queries on a small ets table of around 10,000 records. Basically with around 500 concurrent processes, everything is fine, 1500 I start to notice some small degradation, at around 3000 concurrent processes the schedulers grind to a halt, TOP system CPU usage is around 50%, but Erlang scheduler usage (scheduler:utilization) is 100% and capped out on all 40 threads. I am guessing the schedulers are all waiting on locks on the ets table.? I thought match_object and ets was quite optimized these days, using R22, I am wondering if there is some synchronization/locking issues that could be addressed.? Because I mean at 3000 processes maybe hitting that table 10 times per second on average, does not seem like much. 30k match_objects per second, with ongoing inserts.? Also would there be a way to debug/pinpoint this is the exact issue?? I just did A/B testing where I turned off parts of the system, when I turned off the part that does the match_objects on the ETS table, the system ran fine and never deadlocked at 100% scheduler usage.? Its also hard to profile, as the system is so locked up the profiler barely runs. For now it seems the solution is to rework the architecture and put a second cached view ETS table, so the match_objects can be replaced with key lookups.? Which gets filled by a single process running that pulls via match_object from the main table and fills the cache. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ledest@REDACTED Fri Jan 17 19:09:52 2020 From: ledest@REDACTED (Led) Date: Fri, 17 Jan 2020 20:09:52 +0200 Subject: locked up system using :ets.match_object In-Reply-To: <1519436661.15122799.1579280815081@mail.yahoo.com> References: <1519436661.15122799.1579280815081.ref@mail.yahoo.com> <1519436661.15122799.1579280815081@mail.yahoo.com> Message-ID: > I am having some performance trouble in a system that does a few queries > on a small ets table of around 10,000 records. > > Basically with around 500 concurrent processes, everything is fine, 1500 I > start to notice some small degradation, at around 3000 concurrent processes > the schedulers grind to a halt, TOP system CPU usage is around 50%, but > Erlang scheduler usage (scheduler:utilization) is 100% and capped out on > all 40 threads. > > I am guessing the schedulers are all waiting on locks on the ets table. I > thought match_object and ets was quite optimized these days, using R22, I > am wondering if there is some synchronization/locking issues that could be > addressed. Because I mean at 3000 processes maybe hitting that table 10 > times per second on average, does not seem like much. 30k match_objects per > second, with ongoing inserts. > > Also would there be a way to debug/pinpoint this is the exact issue? I > just did A/B testing where I turned off parts of the system, when I turned > off the part that does the match_objects on the ETS table, the system ran > fine and never deadlocked at 100% scheduler usage. Its also hard to > profile, as the system is so locked up the profiler barely runs. > > For now it seems the solution is to rework the architecture and put a > second cached view ETS table, so the match_objects can be replaced with key > lookups. Which gets filled by a single process running that pulls via > match_object from the main table and fills the cache. > You didn't specify parameters of your table. -- Led. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vans_163@REDACTED Fri Jan 17 20:19:08 2020 From: vans_163@REDACTED (Vans S) Date: Fri, 17 Jan 2020 19:19:08 +0000 (UTC) Subject: locked up system using :ets.match_object In-Reply-To: References: <1519436661.15122799.1579280815081.ref@mail.yahoo.com> <1519436661.15122799.1579280815081@mail.yahoo.com> Message-ID: <1725431880.15253605.1579288748100@mail.yahoo.com> Table parameters are ordered_set,?concurrent read and write. On Friday, January 17, 2020, 01:10:17 p.m. EST, Led wrote: I am having some performance trouble in a system that does a few queries on a small ets table of around 10,000 records. Basically with around 500 concurrent processes, everything is fine, 1500 I start to notice some small degradation, at around 3000 concurrent processes the schedulers grind to a halt, TOP system CPU usage is around 50%, but Erlang scheduler usage (scheduler:utilization) is 100% and capped out on all 40 threads. I am guessing the schedulers are all waiting on locks on the ets table.? I thought match_object and ets was quite optimized these days, using R22, I am wondering if there is some synchronization/locking issues that could be addressed.? Because I mean at 3000 processes maybe hitting that table 10 times per second on average, does not seem like much. 30k match_objects per second, with ongoing inserts.? Also would there be a way to debug/pinpoint this is the exact issue?? I just did A/B testing where I turned off parts of the system, when I turned off the part that does the match_objects on the ETS table, the system ran fine and never deadlocked at 100% scheduler usage.? Its also hard to profile, as the system is so locked up the profiler barely runs. For now it seems the solution is to rework the architecture and put a second cached view ETS table, so the match_objects can be replaced with key lookups.? Which gets filled by a single process running that pulls via match_object from the main table and fills the cache. You didn't specify parameters of your table. -- Led. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sverker@REDACTED Fri Jan 17 20:19:21 2020 From: sverker@REDACTED (Sverker Eriksson) Date: Fri, 17 Jan 2020 20:19:21 +0100 Subject: locked up system using :ets.match_object In-Reply-To: References: <1519436661.15122799.1579280815081.ref@mail.yahoo.com> <1519436661.15122799.1579280815081@mail.yahoo.com> Message-ID: <1579288761.4917.8.camel@erlang.org> On fre, 2020-01-17 at 20:09 +0200, Led wrote: > > I am having some performance trouble in a system that does a few queries on > > a small ets table of around 10,000 records. > > > > Basically with around 500 concurrent processes, everything is fine, 1500 I > > start to notice some small degradation, at around 3000 concurrent processes > > the schedulers grind to a halt, TOP system CPU usage is around 50%, but > > Erlang scheduler usage (scheduler:utilization) is 100% and capped out on all > > 40 threads. > > > > I am guessing the schedulers are all waiting on locks on the ets table.? I > > thought match_object and ets was quite optimized these days, using R22, I am > > wondering if there is some synchronization/locking issues that could be > > addressed.? Because I mean at 3000 processes maybe hitting that table 10 > > times per second on average, does not seem like much. 30k match_objects per > > second, with ongoing inserts.? > > > > Also would there be a way to debug/pinpoint this is the exact issue?? I just > > did A/B testing where I turned off parts of the system, when I turned off > > the part that does the match_objects on the ETS table, the system ran fine > > and never deadlocked at 100% scheduler usage.? Its also hard to profile, as > > the system is so locked up the profiler barely runs. > > > > For now it seems the solution is to rework the architecture and put a second > > cached view ETS table, so the match_objects can be replaced with key > > lookups.? Which gets filled by a single process running that pulls via > > match_object from the main table and fills the cache. > > > You didn't specify parameters of your table. > > And what's the frequency of those inserts that you mention. ets:match_object is a read-only operation and should only inflict lock contention with other write operations, such as ets:insert. /Sverker -------------- next part -------------- An HTML attachment was scrubbed... URL: From vans_163@REDACTED Fri Jan 17 20:27:36 2020 From: vans_163@REDACTED (Vans S) Date: Fri, 17 Jan 2020 19:27:36 +0000 (UTC) Subject: locked up system using :ets.match_object In-Reply-To: <1579288761.4917.8.camel@erlang.org> References: <1519436661.15122799.1579280815081.ref@mail.yahoo.com> <1519436661.15122799.1579280815081@mail.yahoo.com> <1579288761.4917.8.camel@erlang.org> Message-ID: <214182196.15219664.1579289256619@mail.yahoo.com> I really want to measure this so I can have some facts, IMO the performance is degrading way too much for such a small workload.? The frequency is these 3000 processes do 1 write to the table every 15 minutes, so about 3.3 writes per second. (as the processes start at different times). The processes match_object on the table about 30000 times per second, but in bursts, so 10 operations can happen in a single function then it would back off for a few seconds or more. On Friday, January 17, 2020, 02:20:05 p.m. EST, Sverker Eriksson wrote: On fre, 2020-01-17 at 20:09 +0200, Led wrote: I am having some performance trouble in a system that does a few queries on a small ets table of around 10,000 records. Basically with around 500 concurrent processes, everything is fine, 1500 I start to notice some small degradation, at around 3000 concurrent processes the schedulers grind to a halt, TOP system CPU usage is around 50%, but Erlang scheduler usage (scheduler:utilization) is 100% and capped out on all 40 threads. I am guessing the schedulers are all waiting on locks on the ets table.? I thought match_object and ets was quite optimized these days, using R22, I am wondering if there is some synchronization/locking issues that could be addressed.? Because I mean at 3000 processes maybe hitting that table 10 times per second on average, does not seem like much. 30k match_objects per second, with ongoing inserts.? Also would there be a way to debug/pinpoint this is the exact issue?? I just did A/B testing where I turned off parts of the system, when I turned off the part that does the match_objects on the ETS table, the system ran fine and never deadlocked at 100% scheduler usage.? Its also hard to profile, as the system is so locked up the profiler barely runs. For now it seems the solution is to rework the architecture and put a second cached view ETS table, so the match_objects can be replaced with key lookups.? Which gets filled by a single process running that pulls via match_object from the main table and fills the cache. You didn't specify parameters of your table. And what's the frequency of those inserts that you mention. ets:match_object is a read-only operation and should only inflict lock contention with other write operations, such as ets:insert. /Sverker -------------- next part -------------- An HTML attachment was scrubbed... URL: From sverker@REDACTED Fri Jan 17 21:05:48 2020 From: sverker@REDACTED (Sverker Eriksson) Date: Fri, 17 Jan 2020 21:05:48 +0100 Subject: locked up system using :ets.match_object In-Reply-To: <214182196.15219664.1579289256619@mail.yahoo.com> References: <1519436661.15122799.1579280815081.ref@mail.yahoo.com> <1519436661.15122799.1579280815081@mail.yahoo.com> <1579288761.4917.8.camel@erlang.org> <214182196.15219664.1579289256619@mail.yahoo.com> Message-ID: <1579291548.4917.12.camel@erlang.org> Have you tried without read_concurrency? What does ets:info(T, stats) after running for a while? On fre, 2020-01-17 at 19:27 +0000, Vans S wrote: > > I really want to measure this so I can have some facts, IMO the performance is > degrading way too much for such a small workload.? The frequency is these 3000 > processes do 1 write to the table every 15 minutes, so about 3.3 writes per > second. (as the processes start at different times). The processes > match_object on the table about 30000 times per second, but in bursts, so 10 > operations can happen in a single function then it would back off for a few > seconds or more. > On Friday, January 17, 2020, 02:20:05 p.m. EST, Sverker Eriksson > ng.org> wrote: > > > On fre, 2020-01-17 at 20:09 +0200, Led wrote: > > > I am having some performance trouble in a system that does a few queries > > > on a small ets table of around 10,000 records. > > > > > > Basically with around 500 concurrent processes, everything is fine, 1500 I > > > start to notice some small degradation, at around 3000 concurrent > > > processes the schedulers grind to a halt, TOP system CPU usage is around > > > 50%, but Erlang scheduler usage (scheduler:utilization) is 100% and capped > > > out on all 40 threads. > > > > > > I am guessing the schedulers are all waiting on locks on the ets table.? I > > > thought match_object and ets was quite optimized these days, using R22, I > > > am wondering if there is some synchronization/locking issues that could be > > > addressed.? Because I mean at 3000 processes maybe hitting that table 10 > > > times per second on average, does not seem like much. 30k match_objects > > > per second, with ongoing inserts.? > > > > > > Also would there be a way to debug/pinpoint this is the exact issue?? I > > > just did A/B testing where I turned off parts of the system, when I turned > > > off the part that does the match_objects on the ETS table, the system ran > > > fine and never deadlocked at 100% scheduler usage.? Its also hard to > > > profile, as the system is so locked up the profiler barely runs. > > > > > > For now it seems the solution is to rework the architecture and put a > > > second cached view ETS table, so the match_objects can be replaced with > > > key lookups.? Which gets filled by a single process running that pulls via > > > match_object from the main table and fills the cache. > > > > > You didn't specify parameters of your table. > > > > > And what's the frequency of those inserts that you mention. > > ets:match_object is a read-only operation and should only inflict lock > contention with other write operations, such as ets:insert. > > > /Sverker > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vans_163@REDACTED Sat Jan 18 08:01:38 2020 From: vans_163@REDACTED (Vans S) Date: Sat, 18 Jan 2020 07:01:38 +0000 (UTC) Subject: locked up system using :ets.match_object In-Reply-To: <1579291548.4917.12.camel@erlang.org> References: <1519436661.15122799.1579280815081.ref@mail.yahoo.com> <1519436661.15122799.1579280815081@mail.yahoo.com> <1579288761.4917.8.camel@erlang.org> <214182196.15219664.1579289256619@mail.yahoo.com> <1579291548.4917.12.camel@erlang.org> Message-ID: <1309877576.15497095.1579330898598@mail.yahoo.com> The table is a mnesia table so ets:info/2 does not seem to work.? I narrowed it down and it seemed to indeed be match_object just costing too much cpu time and perhaps locking the table. Ended up rewriting the table scanning algo (instead of match_object running around 100 * 2000 times, dump full table once and use Process dictionary to manipulate / filter / organize) and building a cache. The runtime seems stable, it would still be interesting to diagnose those locks does mnesia have something similar to ets:info/2 ? On Friday, January 17, 2020, 03:06:07 p.m. EST, Sverker Eriksson wrote: Have you tried without read_concurrency? What does ets:info(T, stats) after running for a while? On fre, 2020-01-17 at 19:27 +0000, Vans S wrote: I really want to measure this so I can have some facts, IMO the performance is degrading way too much for such a small workload.? The frequency is these 3000 processes do 1 write to the table every 15 minutes, so about 3.3 writes per second. (as the processes start at different times). The processes match_object on the table about 30000 times per second, but in bursts, so 10 operations can happen in a single function then it would back off for a few seconds or more. On Friday, January 17, 2020, 02:20:05 p.m. EST, Sverker Eriksson wrote: On fre, 2020-01-17 at 20:09 +0200, Led wrote: I am having some performance trouble in a system that does a few queries on a small ets table of around 10,000 records. Basically with around 500 concurrent processes, everything is fine, 1500 I start to notice some small degradation, at around 3000 concurrent processes the schedulers grind to a halt, TOP system CPU usage is around 50%, but Erlang scheduler usage (scheduler:utilization) is 100% and capped out on all 40 threads. I am guessing the schedulers are all waiting on locks on the ets table.? I thought match_object and ets was quite optimized these days, using R22, I am wondering if there is some synchronization/locking issues that could be addressed.? Because I mean at 3000 processes maybe hitting that table 10 times per second on average, does not seem like much. 30k match_objects per second, with ongoing inserts.? Also would there be a way to debug/pinpoint this is the exact issue?? I just did A/B testing where I turned off parts of the system, when I turned off the part that does the match_objects on the ETS table, the system ran fine and never deadlocked at 100% scheduler usage.? Its also hard to profile, as the system is so locked up the profiler barely runs. For now it seems the solution is to rework the architecture and put a second cached view ETS table, so the match_objects can be replaced with key lookups.? Which gets filled by a single process running that pulls via match_object from the main table and fills the cache. You didn't specify parameters of your table. And what's the frequency of those inserts that you mention. ets:match_object is a read-only operation and should only inflict lock contention with other write operations, such as ets:insert. /Sverker -------------- next part -------------- An HTML attachment was scrubbed... URL: From dangud@REDACTED Sat Jan 18 09:15:29 2020 From: dangud@REDACTED (Dan Gudmundsson) Date: Sat, 18 Jan 2020 09:15:29 +0100 Subject: locked up system using :ets.match_object In-Reply-To: <1309877576.15497095.1579330898598@mail.yahoo.com> References: <1519436661.15122799.1579280815081.ref@mail.yahoo.com> <1519436661.15122799.1579280815081@mail.yahoo.com> <1579288761.4917.8.camel@erlang.org> <214182196.15219664.1579289256619@mail.yahoo.com> <1579291548.4917.12.camel@erlang.org> <1309877576.15497095.1579330898598@mail.yahoo.com> Message-ID: mnesia:table_info(..) But mnesia is implemented with ets tables so ets:info should work just fine :-) On Sat, Jan 18, 2020 at 8:01 AM Vans S wrote: > The table is a mnesia table so ets:info/2 does not seem to work. I > narrowed it down and it seemed to indeed be match_object just costing too > much cpu time and perhaps locking the table. Ended up rewriting the table > scanning algo (instead of match_object running around 100 * 2000 times, > dump full table once and use Process dictionary to manipulate / filter / > organize) and building a cache. > > The runtime seems stable, it would still be interesting to diagnose those > locks does mnesia have something similar to ets:info/2 ? > > On Friday, January 17, 2020, 03:06:07 p.m. EST, Sverker Eriksson < > sverker@REDACTED> wrote: > > > Have you tried without read_concurrency? > > What does ets:info(T, stats) after running for a while? > > > > On fre, 2020-01-17 at 19:27 +0000, Vans S wrote: > > > I really want to measure this so I can have some facts, IMO the > performance is degrading way too much for such a small workload. The > frequency is these 3000 processes do 1 write to the table every 15 minutes, > so about 3.3 writes per second. (as the processes start at different > times). The processes match_object on the table about 30000 times per > second, but in bursts, so 10 operations can happen in a single function > then it would back off for a few seconds or more. > On Friday, January 17, 2020, 02:20:05 p.m. EST, Sverker Eriksson < > sverker@REDACTED> wrote: > > > On fre, 2020-01-17 at 20:09 +0200, Led wrote: > > I am having some performance trouble in a system that does a few queries > on a small ets table of around 10,000 records. > > Basically with around 500 concurrent processes, everything is fine, 1500 I > start to notice some small degradation, at around 3000 concurrent processes > the schedulers grind to a halt, TOP system CPU usage is around 50%, but > Erlang scheduler usage (scheduler:utilization) is 100% and capped out on > all 40 threads. > > I am guessing the schedulers are all waiting on locks on the ets table. I > thought match_object and ets was quite optimized these days, using R22, I > am wondering if there is some synchronization/locking issues that could be > addressed. Because I mean at 3000 processes maybe hitting that table 10 > times per second on average, does not seem like much. 30k match_objects per > second, with ongoing inserts. > > Also would there be a way to debug/pinpoint this is the exact issue? I > just did A/B testing where I turned off parts of the system, when I turned > off the part that does the match_objects on the ETS table, the system ran > fine and never deadlocked at 100% scheduler usage. Its also hard to > profile, as the system is so locked up the profiler barely runs. > > For now it seems the solution is to rework the architecture and put a > second cached view ETS table, so the match_objects can be replaced with key > lookups. Which gets filled by a single process running that pulls via > match_object from the main table and fills the cache. > > > You didn't specify parameters of your table. > > > > And what's the frequency of those inserts that you mention. > > ets:match_object is a read-only operation and should only inflict lock > contention with other write operations, such as ets:insert. > > > /Sverker > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prof3ta@REDACTED Sat Jan 18 18:51:54 2020 From: prof3ta@REDACTED (Roberto Aloi) Date: Sat, 18 Jan 2020 18:51:54 +0100 Subject: Using an Erlang LSP server with Sublime Text 3 In-Reply-To: References: Message-ID: Hi Torben! I'm using this language server for Erlang: github.com/erlang-ls/erlang_ls Nice that you are taking Erlang LS for a spin. We haven't tried the server with Sublime text yet, so I gave Sublime I try just now (I think I have all possible editors on my laptop now). Disclaimer: I am not a Sublime user, so take my response with a grain of salt. Looking in the console for ST3 I find a complaint about Rebar (the ancient > one, so I'm ignoring that for now) and a problem wrt reading a config file: > Unable to open /Users/torben.hoffmann/Library/Application Support/Sublime > Text 3/Packages/LSP/LSP.sublime-settings > Which is a bit confusing because that file is at > Packages/User/LSP.sublime-settings. > I wouldn't worry about that. It seems the LSP Package for Sublime uses a default settings file (the one in [...]/LSP/LSP.sublime-settings) and one for the user overrides (the one in [...]/User/LSP.sublime-settings). So, what I did to get the connection to the Erlang LS working: Preferences -> Package Settings -> LSP -> Settings Added: { "clients": { "erlang-ls": { "command": [ "/path/to/my/erlang_ls", "--transport", "stdio" ], "enabled": true, "languageId": "erlang", "scopes": [ "source.erlang" ], "syntaxes": [ "Packages/Erlang/Erlang.sublime-syntax" ] } } } Even if I have `erlang_ls` in my $PATH, I had to use an absolute path. I guess there's some way to pass the correct $PATH to Sublime, but I haven't tried that. Some Sublime user may help with that. That's all it was required to get things working. One thing I noticed is that, if you open a single .erl file, Sublime will complain about an error during the error initialization. Instead, you should open the "project" first (i.e. the directory containing your Erlang file), then the file. This seems due to a bug in Erlang LS which always expects a non-null "root path" to be passed during initialization and in Sublime that happens only if you open a directory first. Indeed the LSP protocol specifies that the "root path" can be null, so we will fix that. Fro the time being, please use the workaround. I will add the above to the Erlang LS README. We should also try to get Erlang LS included in the Sublime LSP Package to ease installation. Contributions are always welcome :) But given the nature of the error messages I don't think that is the issue, > at least not yet ;-) Now that you are in Erlang LS land, feel free to use the #language-server channel in the Erlanger Slack or our github issue tracker at github.com/erlang-ls/erlang_ls to get in touch! Best, Roberto -------------- next part -------------- An HTML attachment was scrubbed... URL: From cean.ebengt@REDACTED Sat Jan 18 21:14:46 2020 From: cean.ebengt@REDACTED (bengt) Date: Sat, 18 Jan 2020 21:14:46 +0100 Subject: dbg:p/2 In-Reply-To: <38b8cd55788553942d1acdbaf96a959c4e4b8628@webmail.iinet.net.au> References: <38b8cd55788553942d1acdbaf96a959c4e4b8628@webmail.iinet.net.au> Message-ID: <93A3970B-3F8F-4ABA-BEEC-8CE183FF100D@gmail.com> Greetings, Provided that you have started a receiver (ex: dbg:tracer()) you will then see any message sent to ?registered_name? printed in the Erlang shell. Example of printout (the lines starting with (<0.69.0>)): 2> dbg:tracer(). {ok,<0.66.0>} 3> procslinked:starter(). Receive init_done from P1 {<0.69.0>,okbeud} 4> dbg:p(pidfirstp, [m]). {ok,[{matched,nonode@REDACTED,1}]} Receive init_done from P2 Receive init_done from P3 5> (<0.69.0>) << timeout (<0.69.0>) << {<0.72.0>,init_done} (<0.69.0>) <0.52.0> ! {io_request,<0.69.0>, #Ref<0.4081920205.1462501377.51659>, {put_chars,unicode,io_lib,format, ["Receive init_done from P2~n",[]]}} (<0.69.0>) << {io_reply,#Ref<0.4081920205.1462501377.51659>,ok} Best Wishes, bengt > On 16 Jan 2020, at 04:09, Peter J Etheridge wrote: > > dear friends, > i am trying to debug a message sent. > > when i run; > dbg:p(registered_name, [m]). > > {ok, [{matched,new_node@REDACTED,1}]} > > what is the next step ? > > thank you in advance. > peter > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serge@REDACTED Sun Jan 19 15:17:24 2020 From: serge@REDACTED (Serge Aleynikov) Date: Sun, 19 Jan 2020 09:17:24 -0500 Subject: Custom timer module In-Reply-To: <3591-5e1c5b00-83-124168a0@122384099> References: <3591-5e1c5b00-83-124168a0@122384099> Message-ID: There's a project https://github.com/erlware/erlcron that implements jobs with a timer. It presently maintains persistence through a crontab config file, but it looks like you need something more advanced, so you can take a look at the code, the core of it is just in one module ecrn_agent, and perhaps add a persistence layer. Alternatively, switching your existing implementation to store records in a mnesia disk table would likely be the easiest approach. Best, Serge On Mon, Jan 13, 2020 at 10:33 AM ludovic@REDACTED wrote: > Hello, > > I'm looking for advice about implementing a timer queue in erlang or > elixir. > > Basically what I need is a queue where I can write a timestamp, a key, and > a value. When the local time reaches the timestamp, I want to handle the > key/value (I guess receiving a message with the key and fetch, or receiving > the key/value). > The timer must be cancelable as the value is very small but will lead to > heavy computation. I want to be able to fetch a key from outside of the > process at any time and run the computation (and then cancel the scheduled > computation). > > This is a subset of the `timer` module. But I need to persist the data to > disk and reload on application start. > > I will have a tiny amount of entries : around 1000. > > At the moment I have an ordered_set with `{Timestamp, UserKey} = Key` as > keys, I lookup for the first key and send_after to self the `Key` with > `erlang:start_timer(max(TimeStamp, 1), self(), {run_deletion, Key})`, > which returns a ref that I keep in state so I can ignore timer messages > with an older ref. Everything is done inside a gen_server where I load the > table from disk after init. Also I have to write the table to disk after > each update because it is very important that all events are handled. > > I'm about to implement cancellation but the code becomes messy as I do > both table management and data management in the same module. > > I wonder if there are implementations of this pattern in the community ? I > could use a priority queue, but it seems to me that the implementations use > a fixed list of priorities, and not arbitrary priorities (like a timestamp). > > Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From otp@REDACTED Mon Jan 20 10:42:28 2020 From: otp@REDACTED (Erlang/OTP) Date: Mon, 20 Jan 2020 10:42:28 +0100 (CET) Subject: Patch Package OTP 21.3.8.12 Released Message-ID: <20200120094228.BF0ED254728@hel.cslab.ericsson.net> Patch Package: OTP 21.3.8.12 Git Tag: OTP-21.3.8.12 Date: 2020-01-20 Trouble Report Id: OTP-16371, OTP-16373, OTP-16375, OTP-16376, OTP-16379 Seq num: System: OTP Release: 21 Application: crypto-4.4.2.2, erts-10.3.5.8, ssh-4.7.6.3 Predecessor: OTP 21.3.8.11 Check out the git tag OTP-21.3.8.12, and build a full OTP system including documentation. Apply one or more applications from this build as patches to your installation using the 'otp_patch_apply' tool. For information on install requirements, see descriptions for each application version below. --------------------------------------------------------------------- --- crypto-4.4.2.2 -------------------------------------------------- --------------------------------------------------------------------- The crypto-4.4.2.2 application can be applied independently of other applications on a full OTP 21 installation. --- Fixed Bugs and Malfunctions --- OTP-16376 Application(s): crypto, ssh Constant time comparisons added. Full runtime dependencies of crypto-4.4.2.2: erts-9.0, kernel-5.3, stdlib-3.4 --------------------------------------------------------------------- --- erts-10.3.5.8 --------------------------------------------------- --------------------------------------------------------------------- Note! The erts-10.3.5.8 application *cannot* be applied independently of other applications on an arbitrary OTP 21 installation. On a full OTP 21 installation, also the following runtime dependencies have to be satisfied: -- kernel-6.1 (first satisfied in OTP 21.1) -- sasl-3.3 (first satisfied in OTP 21.2) --- Fixed Bugs and Malfunctions --- OTP-16371 Application(s): erts Taking a scheduler offline could cause timers set while executing on that scheduler to be delayed until the scheduler was put online again. This bug was introduced in ERTS version 10.0 (OTP 21.0). OTP-16379 Application(s): erts A process calling erlang:system_flag(multi_scheduling, block) could end up blocked waiting for the operation to complete indefinitely. Full runtime dependencies of erts-10.3.5.8: kernel-6.1, sasl-3.3, stdlib-3.5 --------------------------------------------------------------------- --- ssh-4.7.6.3 ----------------------------------------------------- --------------------------------------------------------------------- Note! The ssh-4.7.6.3 application *cannot* be applied independently of other applications on an arbitrary OTP 21 installation. On a full OTP 21 installation, also the following runtime dependency has to be satisfied: -- crypto-4.4.2.2 (first satisfied in OTP 21.3.8.12) --- Fixed Bugs and Malfunctions --- OTP-16373 Application(s): ssh Fixed that ssh_connection:send could allocate a large amount of memory if given an iolist() as input data. OTP-16375 Application(s): ssh Safe atom conversions. OTP-16376 Application(s): crypto, ssh Constant time comparisons added. Full runtime dependencies of ssh-4.7.6.3: crypto-4.4.2.2, erts-6.0, kernel-3.0, public_key-1.5.2, stdlib-3.3 --------------------------------------------------------------------- --------------------------------------------------------------------- --------------------------------------------------------------------- From ludovic@REDACTED Mon Jan 20 11:13:29 2020 From: ludovic@REDACTED (=?utf-8?q?ludovic=40demblans=2Ecom?=) Date: Mon, 20 Jan 2020 11:13:29 +0100 Subject: =?utf-8?q?Re=3A?= Custom timer module In-Reply-To: Message-ID: <182e-5e257d80-3f-72d1d780@128154417> Hi, thank you, mnesia could actually be a good fit. I would have to ensure that the schema is created only once (so not being part of the docker container initialization) but that would be better than using tab2file after every write ! I currently have a simple implementation that works well. The only probl?m (really not a problem per se) is that it is just a narrow subset of the timer module. It is based on an ETS ordered_set used as a data structure with a peek function that either returns a timed-out entry or a delay to the next entry timeout ; and a gen_server that just handles `timeout` information and run the the next task and/or returns a timeout according to the delay. As for cron-like application I found that they do not fit well because we sometimes have to pop entries from the table and run them regardless of actual scheduled time. Thanks again Le Dimanche, Janvier 19, 2020 15:17 CET, Serge Aleynikov a ?crit: ?There's a project?https://github.com/erlware/erlcron?that implements jobs with a timer.? It presently maintains persistence through a crontab config file, but it looks like you need something more advanced, so you can take a look at the code, the core of?it is just in one module?ecrn_agent, and perhaps add a persistence layer.?Alternatively, switching your existing implementation to store records in a mnesia disk table would likely be the easiest approach.?Best,?Serge -------------- next part -------------- An HTML attachment was scrubbed... URL: From otp@REDACTED Mon Jan 20 11:46:01 2020 From: otp@REDACTED (Erlang/OTP) Date: Mon, 20 Jan 2020 11:46:01 +0100 (CET) Subject: Patch Package OTP 20.3.8.25 Released Message-ID: <20200120104601.F034725476E@hel.cslab.ericsson.net> Patch Package: OTP 20.3.8.25 Git Tag: OTP-20.3.8.25 Date: 2020-01-20 Trouble Report Id: OTP-16373, OTP-16375, OTP-16376, OTP-16379 Seq num: System: OTP Release: 20 Application: crypto-4.2.2.4, erts-9.3.3.14, ssh-4.6.9.6 Predecessor: OTP 20.3.8.24 Check out the git tag OTP-20.3.8.25, and build a full OTP system including documentation. Apply one or more applications from this build as patches to your installation using the 'otp_patch_apply' tool. For information on install requirements, see descriptions for each application version below. --------------------------------------------------------------------- --- crypto-4.2.2.4 -------------------------------------------------- --------------------------------------------------------------------- The crypto-4.2.2.4 application can be applied independently of other applications on a full OTP 20 installation. --- Fixed Bugs and Malfunctions --- OTP-16376 Application(s): crypto, ssh Constant time comparisons added. Full runtime dependencies of crypto-4.2.2.4: erts-9.0, kernel-5.3, stdlib-3.4 --------------------------------------------------------------------- --- erts-9.3.3.14 --------------------------------------------------- --------------------------------------------------------------------- The erts-9.3.3.14 application can be applied independently of other applications on a full OTP 20 installation. --- Fixed Bugs and Malfunctions --- OTP-16379 Application(s): erts A process calling erlang:system_flag(multi_scheduling, block) could end up blocked waiting for the operation to complete indefinitely. Full runtime dependencies of erts-9.3.3.14: kernel-5.0, sasl-3.0.1, stdlib-3.0 --------------------------------------------------------------------- --- ssh-4.6.9.6 ----------------------------------------------------- --------------------------------------------------------------------- Note! The ssh-4.6.9.6 application *cannot* be applied independently of other applications on an arbitrary OTP 20 installation. On a full OTP 20 installation, also the following runtime dependencies have to be satisfied: -- crypto-4.2.2.4 (first satisfied in OTP 20.3.8.25) -- public_key-1.5.2 (first satisfied in OTP 20.2) --- Fixed Bugs and Malfunctions --- OTP-16373 Application(s): ssh Fixed that ssh_connection:send could allocate a large amount of memory if given an iolist() as input data. OTP-16375 Application(s): ssh Safe atom conversions. OTP-16376 Application(s): crypto, ssh Constant time comparisons added. Full runtime dependencies of ssh-4.6.9.6: crypto-4.2.2.4, erts-6.0, kernel-3.0, public_key-1.5.2, stdlib-3.3 --------------------------------------------------------------------- --------------------------------------------------------------------- --------------------------------------------------------------------- From otp@REDACTED Mon Jan 20 12:41:46 2020 From: otp@REDACTED (Erlang/OTP) Date: Mon, 20 Jan 2020 12:41:46 +0100 (CET) Subject: Patch Package OTP 22.2.3 Released Message-ID: <20200120114146.D71A8254798@hel.cslab.ericsson.net> Patch Package: OTP 22.2.3 Git Tag: OTP-22.2.3 Date: 2020-01-20 Trouble Report Id: OTP-16385, OTP-16388, OTP-16396 Seq num: ERL-1118, ERL-1128, ERL-1130 System: OTP Release: 22 Application: compiler-7.5.1, ssl-9.5.2 Predecessor: OTP 22.2.2 Check out the git tag OTP-22.2.3, and build a full OTP system including documentation. Apply one or more applications from this build as patches to your installation using the 'otp_patch_apply' tool. For information on install requirements, see descriptions for each application version below. --------------------------------------------------------------------- --- compiler-7.5.1 -------------------------------------------------- --------------------------------------------------------------------- The compiler-7.5.1 application can be applied independently of other applications on a full OTP 22 installation. --- Fixed Bugs and Malfunctions --- OTP-16385 Application(s): compiler Related Id(s): ERL-1128 Fixed a bug in the compiler that could cause it to reject valid code. Full runtime dependencies of compiler-7.5.1: crypto-3.6, erts-9.0, hipe-3.12, kernel-4.0, stdlib-2.5 --------------------------------------------------------------------- --- ssl-9.5.2 ------------------------------------------------------- --------------------------------------------------------------------- The ssl-9.5.2 application can be applied independently of other applications on a full OTP 22 installation. --- Fixed Bugs and Malfunctions --- OTP-16388 Application(s): ssl Related Id(s): ERL-1130 Fix the handling of GREASE values sent by web browsers when establishing TLS 1.3 connections. This change improves handling of GREASE values in various protocol elements sent in a TLS 1.3 ClientHello. OTP-16396 Application(s): ssl Related Id(s): ERL-1118 Correct DTLS listen emulation, could cause problems with opening a new DTLS listen socket for a port previously used by a now closed DTLS listen socket. Full runtime dependencies of ssl-9.5.2: crypto-4.2, erts-10.0, inets-5.10.7, kernel-6.0, public_key-1.5, stdlib-3.5 --------------------------------------------------------------------- --------------------------------------------------------------------- --------------------------------------------------------------------- From zxq9@REDACTED Tue Jan 21 10:55:21 2020 From: zxq9@REDACTED (zxq9) Date: Tue, 21 Jan 2020 18:55:21 +0900 Subject: wx:batch/1 on Windows 10 Message-ID: <6aaea33c-24a7-2f7f-0387-f887762f0c22@zxq9.com> I have been working on a tool kit to make project creation, distribution, launching from source, etc. a bit smoother for cross platform Erlang apps (particularly client-side) and have hit a susprising snag: wx:batch/1 doesn't seem to have any effect on Windows. Due to this the GUI app browser and launcher windows populate in a glitchy way, Observer graphs flicker, and other marginally annoying phenomena occur -- but only on Windows. You can observe this by running wx:demo() and selecting any example frame that has multiple components. I get this effect with R22.2 on Windows 10, but haven't confirmed how far back this bug exists (this problem did not occur previously around the time of R18 on Windows 7). Would this be an issue with Windows, WX lib version, build config (I'm using the Windows x64 binary installer), graphics drivers, etc? Any ideas would be appreciated. It is still possible to write and run meaningful apps, of course (and they work great on other platforms) but Windows is a pretty important target for client-side code. -Craig From dangud@REDACTED Tue Jan 21 11:47:08 2020 From: dangud@REDACTED (Dan Gudmundsson) Date: Tue, 21 Jan 2020 11:47:08 +0100 Subject: wx:batch/1 on Windows 10 In-Reply-To: <6aaea33c-24a7-2f7f-0387-f887762f0c22@zxq9.com> References: <6aaea33c-24a7-2f7f-0387-f887762f0c22@zxq9.com> Message-ID: wx:batch() was originally intended as optimization, by not letting wxWidgets get control until the complete work batch was done. I.e. a faster interface to the executing thread. I have optimized the code since then and on linux batch is not needed, I have changed so that events are checked (temporary allow wxWidgets to check/handle events) every forth batch otherwise event handling could be starved when to many large batches where sent to wx thread. But I have also noticed the problem, starting observer on a slow computer shows the problem, and I have tried to revert the changes mentioned above but I have not managed to figure out what have changed. One thing that have changed is wxWidgets version, i.e. upgrade from 2.8 to 3.0.3 (soon to be 3.1 on windows), but I don't know what is causing this, nor how where is should be fixed in the application code, wx wrapper or wxwidgets library. On Tue, Jan 21, 2020 at 10:55 AM zxq9 wrote: > I have been working on a tool kit to make project creation, > distribution, launching from source, etc. a bit smoother for cross > platform Erlang apps (particularly client-side) and have hit a > susprising snag: wx:batch/1 doesn't seem to have any effect on Windows. > > Due to this the GUI app browser and launcher windows populate in a > glitchy way, Observer graphs flicker, and other marginally annoying > phenomena occur -- but only on Windows. > > You can observe this by running wx:demo() and selecting any example > frame that has multiple components. > > I get this effect with R22.2 on Windows 10, but haven't confirmed how > far back this bug exists (this problem did not occur previously around > the time of R18 on Windows 7). > > Would this be an issue with Windows, WX lib version, build config (I'm > using the Windows x64 binary installer), graphics drivers, etc? > > Any ideas would be appreciated. It is still possible to write and run > meaningful apps, of course (and they work great on other platforms) but > Windows is a pretty important target for client-side code. > > -Craig > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zxq9@REDACTED Tue Jan 21 12:08:38 2020 From: zxq9@REDACTED (zxq9) Date: Tue, 21 Jan 2020 20:08:38 +0900 Subject: wx:batch/1 on Windows 10 In-Reply-To: References: <6aaea33c-24a7-2f7f-0387-f887762f0c22@zxq9.com> Message-ID: On 2020/01/21 19:47, Dan Gudmundsson wrote: > wx:batch() was originally intended as optimization, by not letting > wxWidgets get control until the > complete work batch was done. I.e. a faster interface to the executing > thread. > > I have optimized the code since then and on linux batch is not needed, I > have changed > so that events are checked (temporary allow wxWidgets to check/handle > events) every forth batch otherwise > event handling could be starved when to many large batches where sent to > wx thread. > > But I have also noticed the problem, starting observer on a slow > computer shows the problem, > and I have tried to revert the changes mentioned above but I have not > managed?to figure out what > have changed. > > One thing that have changed is wxWidgets version, i.e. upgrade from 2.8 > to 3.0.3 (soon to be 3.1 on windows), > but I don't know what is causing this, nor how where is should be fixed > in the application code, > ?wx wrapper or wxwidgets library. I've just tested R17 through R22.2 and they all have this issue on Windows 10, which surprises me. I'll go back and check Windows 7 later, and see if I can find some other graphics hardware to see if that makes a difference. Anyway, wxWindow:freeze/1 and wxWindow:thaw/1 both exist on our interface, so I might be able to make this work as expected using this technique directly. I'll let you know how it goes. I'm not sure about the flicker on Windows with Observer graphs. The difference in refresh rate is really surprising. May just need more explicit control of when to blit: https://wiki.wxwidgets.org/Flicker-Free_Drawing GL canvasses work beautifully, by the way, so no trouble there so far. (Too bad 3D widget sets/interfaces aren't the norm!) -Craig From jesper.louis.andersen@REDACTED Tue Jan 21 14:44:27 2020 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Tue, 21 Jan 2020 14:44:27 +0100 Subject: Custom timer module In-Reply-To: <182e-5e257d80-3f-72d1d780@128154417> References: <182e-5e257d80-3f-72d1d780@128154417> Message-ID: On Mon, Jan 20, 2020 at 11:13 AM ludovic@REDACTED wrote: > Hi, thank you, mnesia could actually be a good fit. I would have to ensure > that the schema is created only once (so not being part of the docker > container initialization) but that would be better than using tab2file > after every write ! > > The route I usually take is to create the schema and produce a FALLBACK.BUP file. You then attach persistent storage to your docker container and arrange that the storage starts out with the FALLBACK.BUP. On first startup, this file unpacks itself into your pristine mnesia schema. And from then on, you have persistent storage. It is usually fair easier to handle than trying to figure out if there is a schema and create it dynamically. There is a rough overview in the GraphQL tutorial I wrote a couple years back: https://shopgun.github.io/graphql-erlang-tutorial/#_mnesia (scroll up a bit and also read "Mnesia initialization" As for your problem: * Think about system_time vs monotonic time. You probably want to track system_time for jobs since monotonic is not persistence-safe, but this creates trouble with leap seconds. * Track UTC to avoid daylight saving time. * system_time requires you to handle NTP time jumps. At least monitor them and log them. Think about the warp mode you want for the Erlang node. * At 1000 entries, full scans to cancel stuff isn't a problem. If it ever becomes, store both {TS, K, V} and {K, TS} in the table. Then you can quickly cancel K. * One process is authoritative for the table. This guarantees serialization. * Spawn processes to handle K/V pairs. There are at most 1000 of them. * ordered_set is the way to go. If we have Now, you wake up and find every record with TS < Now up to a limit (25, say). You then handle those and remove them. Cycle 25 at a time, since this limits a spawn-spike if you suddenly have many timers going off at the same time. Especially important if your work is resource-intensive. You can use e.g., monitors to track the worker-count. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roger@REDACTED Tue Jan 21 15:57:13 2020 From: roger@REDACTED (Roger Lipscombe) Date: Tue, 21 Jan 2020 14:57:13 +0000 Subject: Custom timer module In-Reply-To: References: <182e-5e257d80-3f-72d1d780@128154417> Message-ID: On Tue, 21 Jan 2020 at 13:45, Jesper Louis Andersen wrote: > * Track UTC to avoid daylight saving time. Unless your timestamps are *intended* to be in user's local time. This is a problem with (e.g.) remote management/deployment solutions: the user actually *wants* their OS upgrade to be scheduled in their timezone, according to the daylight saving rules for then, not now. From jesper.louis.andersen@REDACTED Tue Jan 21 16:39:31 2020 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Tue, 21 Jan 2020 16:39:31 +0100 Subject: Custom timer module In-Reply-To: References: <182e-5e257d80-3f-72d1d780@128154417> Message-ID: On Tue, Jan 21, 2020 at 3:57 PM Roger Lipscombe wrote: > Unless your timestamps are *intended* to be in user's local time. This > is a problem with (e.g.) remote management/deployment solutions: the > user actually *wants* their OS upgrade to be scheduled in their > timezone, according to the daylight saving rules for then, not now. > That is a separate problem in my book. Your system will have an internal representation, which you should treat as abstract/unknown. And there is an external representation which you use to enter and extract points-in-time. If you want an OS upgrade to happen at 02:00am ET, you then provide that to your marshal function, and it converts that to your internal representation. If you want this point-in-time in, say, CET, you then extract it from the internal representation into a string where CET is the timezone. You can choose any internal representation and reference. {Mega, Secs, Micro}, nanoseconds, gregorian basepoint, 1/1 1970 basepoint, floating point, a record, ... as long as you can marhsal/unmarshal. However, there are some internal representations which are going to be easier to work with. UNIX uses seconds after 1/1 1970, and keeping that at UTC makes things a tad easier as well in the long run. Consider if the machine roams. Now you can do: $ TZ='EST' /bin/date Tue 21 Jan 2020 10:32:40 AM EST $ TZ='CET' /bin/date Tue 21 Jan 2020 04:32:57 PM CET This is also useful if multiple people are using the machine, but from different time zones. It is the same internal representation, but our presentation changes and switches based on where we are located. If you make the choice your internal representation moves with the timezone, and you have a roaming system, then you have to rewrite all timestamps on timezone changes. Or you have to keep a non-UTC timezone as the base, but this is not common. Non-UTC timezones are also a hassle if you ever need to combine log files from multiple data center locations each running with their own timezone. My experience is that it is often easier to do this conversion in the border of your system and then work with a UTC-reference internally. Otherwise, you end up with the need to do conversions on demand in your code. This is certainly doable in languages with type systems, as the type system can protect you against incorrect use. But in a uni-typed world where everything is a term, you usually want a simple representation. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From torben.lehoff@REDACTED Tue Jan 21 17:35:23 2020 From: torben.lehoff@REDACTED (Torben Hoffmann) Date: Tue, 21 Jan 2020 19:35:23 +0300 Subject: Using an Erlang LSP server with Sublime Text 3 In-Reply-To: References: Message-ID: Hi Roberto, Thanks for taking the time to look into this. Sorry about the lag - I'm on a business trip and have been rather busy. I have tried using your config settings, but I still get the "Unable to open?" error message and there is no Erlang LS in sight when I try to enable it. At this point I'm suspecting that this is a problem between Sublime and LSP, so I'll try to get some help on that. I will report back with my findings. Cheers, Torben On Sat, 18 Jan 2020 at 20:52, Roberto Aloi wrote: > Hi Torben! > > I'm using this language server for Erlang: github.com/erlang-ls/erlang_ls > > > Nice that you are taking Erlang LS for a spin. We haven't tried the server > with Sublime text yet, so I gave Sublime I try just now (I think I have all > possible editors on my laptop now). Disclaimer: I am not a Sublime user, so > take my response with a grain of salt. > > Looking in the console for ST3 I find a complaint about Rebar (the ancient >> one, so I'm ignoring that for now) and a problem wrt reading a config file: >> Unable to open /Users/torben.hoffmann/Library/Application Support/Sublime >> Text 3/Packages/LSP/LSP.sublime-settings >> Which is a bit confusing because that file is at >> Packages/User/LSP.sublime-settings. >> > > I wouldn't worry about that. It seems the LSP Package for Sublime uses a > default settings file (the one in [...]/LSP/LSP.sublime-settings) > and one for the user overrides (the one in > [...]/User/LSP.sublime-settings). > > So, what I did to get the connection to the Erlang LS working: > > Preferences -> Package Settings -> LSP -> Settings > > Added: > > { > "clients": > { > "erlang-ls": > { > "command": > [ > "/path/to/my/erlang_ls", "--transport", "stdio" > ], > "enabled": true, > "languageId": "erlang", > "scopes": > [ > "source.erlang" > ], > "syntaxes": > [ > "Packages/Erlang/Erlang.sublime-syntax" > ] > } > } > } > > Even if I have `erlang_ls` in my $PATH, I had to use an absolute path. I > guess there's some way to pass the correct $PATH to Sublime, but I haven't > tried that. Some Sublime user may help with that. > That's all it was required to get things working. One thing I noticed is > that, if you open a single .erl file, Sublime will complain about an error > during the error initialization. > Instead, you should open the "project" first (i.e. the directory > containing your Erlang file), then the file. This seems due to a bug in > Erlang LS which always expects a non-null "root path" to be passed during > initialization and in Sublime that happens only if you open a directory > first. Indeed the LSP protocol specifies that the "root path" can be null, > so we will fix that. Fro the time being, please use the workaround. > > I will add the above to the Erlang LS README. We should also try to get > Erlang LS included in the Sublime LSP Package to ease installation. > Contributions are always welcome :) > > But given the nature of the error messages I don't think that is >> the issue, at least not yet ;-) > > Now that you are in Erlang LS land, feel free to use the #language-server > channel in the Erlanger Slack or our github issue tracker at > github.com/erlang-ls/erlang_ls to get in touch! > > Best, > > Roberto > > -- http://www.linkedin.com/in/torbenhoffmann @LeHoff -------------- next part -------------- An HTML attachment was scrubbed... URL: From ludovic@REDACTED Tue Jan 21 20:33:23 2020 From: ludovic@REDACTED (=?utf-8?q?ludovic=40demblans=2Ecom?=) Date: Tue, 21 Jan 2020 20:33:23 +0100 Subject: =?utf-8?q?Re=3A?= Custom timer module In-Reply-To: Message-ID: <56a6-5e275200-39-78832f00@169090850> Thank you very much for those advices, I'll see if I can apply that to my code ! Cheers Le Mardi, Janvier 21, 2020 14:44 CET, Jesper Louis Andersen a ?crit: ?On Mon, Jan 20, 2020 at 11:13 AM ludovic@REDACTED wrote:Hi, thank you, mnesia could actually be a good fit. I would have to ensure that the schema is created only once (so not being part of the docker container initialization) but that would be better than using tab2file after every write ! ??The route I usually take is to create the schema and produce a FALLBACK.BUP file. You then attach persistent storage to your docker container and arrange that the storage starts out with the FALLBACK.BUP. On first startup, this file unpacks itself into your pristine mnesia schema. And from then on, you have persistent storage. It is usually fair easier to handle than trying to figure out if there is a schema and create it dynamically. There is a rough overview in the GraphQL tutorial I wrote a couple years back:?https://shopgun.github.io/graphql-erlang-tutorial/#_mnesia?(scroll up a bit and also read "Mnesia initialization"?As for your problem:?* Think about system_time vs monotonic time. You probably want to track system_time for jobs since monotonic is not persistence-safe, but this creates trouble with leap seconds.* Track UTC to avoid daylight saving time.* system_time requires you to handle NTP time jumps. At least monitor them and log them. Think about the warp mode you want for the Erlang node.* At 1000 entries, full scans to cancel stuff isn't a problem. If it ever becomes, store both {TS, K, V} and {K, TS} in the table. Then you can quickly cancel K.* One process is authoritative for the table. This guarantees serialization.* Spawn processes to handle K/V pairs. There are at most 1000 of them.* ordered_set is the way to go. If we have Now, you wake up and find every record with TS < Now up to a limit (25, say). You then handle those and remove them. Cycle 25 at a time, since this limits a spawn-spike if you suddenly have many timers going off at the same time. Especially important if your work is resource-intensive. You can use e.g., monitors to track the worker-count.?? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From vances@REDACTED Wed Jan 22 06:18:51 2020 From: vances@REDACTED (Vance Shipley) Date: Wed, 22 Jan 2020 13:18:51 +0800 Subject: [ANN] snmp_simulator In-Reply-To: References: Message-ID: SigScale's snmp_simulator application implements the [ITU-]ALARM-MIB (RFC3788) as an agent simulation used to load test alarm managers. You may import your own alarm models to generate random but realistic content in SNMP notifications at a target rate with random deviation. https://github.com/sigscale/snmp-simulator On Mon, Sep 23, 2019 at 2:40 PM Vance Shipley wrote: > The snmp application in OTP does include a manager however it is not > very useful in real world use cases. For our purposes we started with > it but evolved to writing our own manager while making it an > incremental addition to the existing snmp application. Additions > include SNMP engine ID discovery and NIFs for SNMPv3 crypto. > > The result is available in our snmp_collector application available > here: https://github.com/sigscale/snmp-collector > -- -Vance -------------- next part -------------- An HTML attachment was scrubbed... URL: From zxq9@REDACTED Sun Jan 26 02:59:23 2020 From: zxq9@REDACTED (zxq9) Date: Sun, 26 Jan 2020 10:59:23 +0900 Subject: wx:batch/1 on Windows 10 In-Reply-To: References: <6aaea33c-24a7-2f7f-0387-f887762f0c22@zxq9.com> <53df9f84-d099-9ba9-f3a5-5b95c6b8bb09@zxq9.com> Message-ID: On 2020/01/21 20:16, Dan Gudmundsson wrote: > > One thing that have changed is wxWidgets version, i.e. upgrade > from 2.8 > > to 3.0.3 (soon to be 3.1 on windows), > > but I don't know what is causing this, nor how where is should be > fixed > > in the application code, > >? ?wx wrapper or wxwidgets library. Hi, again. After confirming the behavior (and also finding that freeze/1, [make stuff], thaw/1 doesn't work on Windows) someone in the SO Erlang channel found this bug that has been around forever and seems to apply only to wxMSW: https://trac.wxwidgets.org/ticket/10748 The description is exactly the problem I see. Hopefully they'll get this cleared up. It is a very weird problem. I imagine I can create a workaround, but will need a few hours to mess with it to figure out a way. If they fix freeze/thaw on all platforms then a non-hacky implementation of batch/1 could be: -spec batch(Window, Fun) -> Result when Window :: wx:wx_object(), Fun :: fun(), Result :: term(). batch(Window, Fun) -> ok = wxWindow:freeze(Window), Result = Fun(), ok = wxWindow:thaw(Window), Result. Fingers crossed this is addressed in 3.1. -Craig From frank.muller.erl@REDACTED Sun Jan 26 13:58:04 2020 From: frank.muller.erl@REDACTED (Frank Muller) Date: Sun, 26 Jan 2020 13:58:04 +0100 Subject: Instrumenting Erlang code Message-ID: Hi everyone I would like to implement a custom instrumentation module for my Erlang code. Let assume this function: f1() -> ? code here ? ok. When instrumenting this function, I would like it to look like: f1() -> instrument:start(), ? code here ? instrument:end(), instrument:start(), receive -> {msg1, M1} -> instrument:end(), M1; {msg2, M2} -> instrument:end(), M2; _ -> instrument:end(), f2() end. Is that doable? If yes, can I apply like this logic to all modules running in my Erlang node? @Kostis: does Concuerror (https://github.com/parapluu/Concuerror) use this technique? Thanks for you help. /Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Sun Jan 26 14:28:51 2020 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Sun, 26 Jan 2020 14:28:51 +0100 Subject: Instrumenting Erlang code In-Reply-To: References: Message-ID: On Sun, Jan 26, 2020 at 1:58 PM Frank Muller wrote: > Hi everyone > > I would like to implement a custom instrumentation module for my Erlang > code. > Let assume this function: > > If you have f1() -> Exprs, ok. You can write f1() -> S = instrument:start(), try Exprs, ok finally instrument:end(S) end. However, some times you want to track an error apart from a success value. Positive and negative exit paths often require different instrumentation. The success path is often interested in processing time (latency) in addition to processing count. The error path often centers around the idea of an error count, especially if the exit is fast. If you blend them, the problem is that the fast errors muddles your view of the successes, as your latency distribution becomes multi-modal. In turn, your mean and median doesn't work like you think they do anymore. > Other problem I can think of is when we have multiple return paths and/or > recursive loop: > > If you loop, you want to wrap: f1(0) -> ok; f1(N) -> do(), f(N-1). f1_(N) -> S = instrument:start(), try f1(N) finally instrument:end(S) end. This only pushes a single exception handler to the stack. An important caveat is when Exprs or do() hibernates. Beware of that situation, since it removes the stack and invokes a continuation. > Is that doable? > If yes, can I apply like this logic to all modules running in my Erlang > node? > > Yes, parse transforms. But in my experience, applying something to all modules is usually the wrong way to go about instrumentation. Maybe with a -instrument([F, ...]). to help the parsetransform along the way. ( This is considerably easier in something like Elixir with its macro system, or OCaml, because you have PPX extensions. In OCaml, you would have let f1() -> Expr. And you could just annotate it let%instrument f1() -> Expr. And write a PPX rewriter for that. ) -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjtruog@REDACTED Sun Jan 26 18:46:39 2020 From: mjtruog@REDACTED (Michael Truog) Date: Sun, 26 Jan 2020 09:46:39 -0800 Subject: Instrumenting Erlang code In-Reply-To: References: Message-ID: <9cf863a2-8c61-3771-8e57-1499b660db43@gmail.com> On 1/26/20 4:58 AM, Frank Muller wrote: > Hi everyone > > I would like to implement a custom instrumentation module for my > Erlang code. > Let assume this function: > You are describing that you need aspects from aspect oriented programming (that should be the best concept for what you want, when thinking about the problem).? I implemented this in CloudI (https://cloudi.org) as a list of functions that are executed in order with separate lists for before and after a callback function.? My approach used the following to represent a function [1]: {Module :: atom(), Function :: atom()} to represent a function of the expected arity (call it arity N), and: {{Module :: atom(), Function :: atom()}} to represent a function of arity 0 that returns a function of arity N, or a normal Erlang function.? Representing the function as a tuple with atoms allows specifying the function before it is loaded.? Using the arity 0 function indirection allows execution of source code before the function is created, normally when a function retains variables created before the function is created (a closure).? Using this approach made it easy to add monitoring to CloudI services and other things like batch execution of CloudI services. Using functions as data (configuration for the source code [2]) avoids source code that lacks transparency, like macros or parse transforms. Best Regards, Michael [1] Example type specification https://github.com/CloudI/CloudI/blob/7cac9108827ce58008eac7aa24e192c44e2fbfd6/src/lib/cloudi_core/src/cloudi_service_api.erl#L203-L205 [2] Example configuration of aspects https://github.com/CloudI/CloudI/blob/7cac9108827ce58008eac7aa24e192c44e2fbfd6/src/lib/cloudi_core/src/cloudi_service_api.erl#L429-L434 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vans_163@REDACTED Sun Jan 26 19:38:27 2020 From: vans_163@REDACTED (Vans S) Date: Sun, 26 Jan 2020 18:38:27 +0000 (UTC) Subject: locked up system using :ets.match_object In-Reply-To: References: <1519436661.15122799.1579280815081.ref@mail.yahoo.com> <1519436661.15122799.1579280815081@mail.yahoo.com> <1579288761.4917.8.camel@erlang.org> <214182196.15219664.1579289256619@mail.yahoo.com> <1579291548.4917.12.camel@erlang.org> <1309877576.15497095.1579330898598@mail.yahoo.com> Message-ID: <2009971725.20071843.1580063907481@mail.yahoo.com> I ended up using microstate accounts plus lock counting. ETS locks and MSAC was quite low.? Surprisingly I ended up having very high contention for the memory allocator,? msac showed aux and allocator using around 15-30% each (not sure if these 2 values combine or are seperate).? Again to refresh, my problem was I had 100% scheduler CPU usage (backed up runqueue) with only 50% system cpu usage. I ended up bumping the minimal heapsize by a large order of magnitude to the average words count the worker processes were using.? Dropped the lock contention on alloc and scheduler usage in alloc to near 0, also aux dropped by a large amount. I noticed when doing this some processes spiked insanely in their memory allocated, I am wondering if theres a way to profile this? The ideal scenario would be, line number + amount of objects allocated / type of object.? A still good scenario, process pid + objects (so can inspect them for what they are).? A pretty hard to debug scenario, just the memory consumption and type. On Saturday, January 18, 2020, 03:15:41 a.m. EST, Dan Gudmundsson wrote: mnesia:table_info(..) But mnesia is implemented with ets tables so ets:info should work just fine :-) On Sat, Jan 18, 2020 at 8:01 AM Vans S wrote: The table is a mnesia table so ets:info/2 does not seem to work.? I narrowed it down and it seemed to indeed be match_object just costing too much cpu time and perhaps locking the table. Ended up rewriting the table scanning algo (instead of match_object running around 100 * 2000 times, dump full table once and use Process dictionary to manipulate / filter / organize) and building a cache. The runtime seems stable, it would still be interesting to diagnose those locks does mnesia have something similar to ets:info/2 ? On Friday, January 17, 2020, 03:06:07 p.m. EST, Sverker Eriksson wrote: Have you tried without read_concurrency? What does ets:info(T, stats) after running for a while? On fre, 2020-01-17 at 19:27 +0000, Vans S wrote: I really want to measure this so I can have some facts, IMO the performance is degrading way too much for such a small workload.? The frequency is these 3000 processes do 1 write to the table every 15 minutes, so about 3.3 writes per second. (as the processes start at different times). The processes match_object on the table about 30000 times per second, but in bursts, so 10 operations can happen in a single function then it would back off for a few seconds or more. On Friday, January 17, 2020, 02:20:05 p.m. EST, Sverker Eriksson wrote: On fre, 2020-01-17 at 20:09 +0200, Led wrote: I am having some performance trouble in a system that does a few queries on a small ets table of around 10,000 records. Basically with around 500 concurrent processes, everything is fine, 1500 I start to notice some small degradation, at around 3000 concurrent processes the schedulers grind to a halt, TOP system CPU usage is around 50%, but Erlang scheduler usage (scheduler:utilization) is 100% and capped out on all 40 threads. I am guessing the schedulers are all waiting on locks on the ets table.? I thought match_object and ets was quite optimized these days, using R22, I am wondering if there is some synchronization/locking issues that could be addressed.? Because I mean at 3000 processes maybe hitting that table 10 times per second on average, does not seem like much. 30k match_objects per second, with ongoing inserts.? Also would there be a way to debug/pinpoint this is the exact issue?? I just did A/B testing where I turned off parts of the system, when I turned off the part that does the match_objects on the ETS table, the system ran fine and never deadlocked at 100% scheduler usage.? Its also hard to profile, as the system is so locked up the profiler barely runs. For now it seems the solution is to rework the architecture and put a second cached view ETS table, so the match_objects can be replaced with key lookups.? Which gets filled by a single process running that pulls via match_object from the main table and fills the cache. You didn't specify parameters of your table. And what's the frequency of those inserts that you mention. ets:match_object is a read-only operation and should only inflict lock contention with other write operations, such as ets:insert. /Sverker -------------- next part -------------- An HTML attachment was scrubbed... URL: From vans_163@REDACTED Sun Jan 26 19:41:19 2020 From: vans_163@REDACTED (Vans S) Date: Sun, 26 Jan 2020 18:41:19 +0000 (UTC) Subject: Instrumenting Erlang code In-Reply-To: <9cf863a2-8c61-3771-8e57-1499b660db43@gmail.com> References: <9cf863a2-8c61-3771-8e57-1499b660db43@gmail.com> Message-ID: <1364287934.20043536.1580064079923@mail.yahoo.com> On this topic, is there a way to attach instrumentation on the fly in a running system?? That can give you a callback onentry and onexit? To profile wall time and perhap do conditional matching / stack trace inspection. To see which calls trigger the slow path for example. On Sunday, January 26, 2020, 12:46:57 p.m. EST, Michael Truog wrote: On 1/26/20 4:58 AM, Frank Muller wrote: Hi everyone I would like to implement a custom instrumentation module for my Erlang code. Let assume this function: You are describing that you need aspects from aspect oriented programming (that should be the best concept for what you want, when thinking about the problem).? I implemented this in CloudI (https://cloudi.org) as a list of functions that are executed in order with separate lists for before and after a callback function.? My approach used the following to represent a function [1]: {Module :: atom(), Function :: atom()} to represent a function of the expected arity (call it arity N), and: {{Module :: atom(), Function :: atom()}} to represent a function of arity 0 that returns a function of arity N, or a normal Erlang function.? Representing the function as a tuple with atoms allows specifying the function before it is loaded.? Using the arity 0 function indirection allows execution of source code before the function is created, normally when a function retains variables created before the function is created (a closure).? Using this approach made it easy to add monitoring to CloudI services and other things like batch execution of CloudI services. Using functions as data (configuration for the source code [2]) avoids source code that lacks transparency, like macros or parse transforms. Best Regards, Michael [1] Example type specificationhttps://github.com/CloudI/CloudI/blob/7cac9108827ce58008eac7aa24e192c44e2fbfd6/src/lib/cloudi_core/src/cloudi_service_api.erl#L203-L205 [2] Example configuration of aspectshttps://github.com/CloudI/CloudI/blob/7cac9108827ce58008eac7aa24e192c44e2fbfd6/src/lib/cloudi_core/src/cloudi_service_api.erl#L429-L434 -------------- next part -------------- An HTML attachment was scrubbed... URL: From t@REDACTED Sun Jan 26 20:22:57 2020 From: t@REDACTED (Tristan Sloughter) Date: Sun, 26 Jan 2020 12:22:57 -0700 Subject: Instrumenting Erlang code In-Reply-To: References: Message-ID: On Sun, Jan 26, 2020, at 05:58, Frank Muller wrote: > Is that doable? > If yes, can I apply like this logic to all modules running in my Erlang node? The cases you mention are exactly why it is best to not attempt to apply the logic throughout the code automatically but to write it manually where it makes sense to do so. Except in the case of live tracing, where you can use matchspecs to setup traces on functions you care about. I'd also suggest checking out existing instrumentation libraries for Erlang, so maybe you don't need to write your own: - https://github.com/open-telemetry/opentelemetry-erlang-api/ implementation of the https://opentelemetry.io/ spec. - https://github.com/beam-telemetry/telemetry As well as the Foundation's Observability working group, https://github.com/erlef/eef-observability-wg/ Tristan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjtruog@REDACTED Mon Jan 27 00:00:52 2020 From: mjtruog@REDACTED (Michael Truog) Date: Sun, 26 Jan 2020 15:00:52 -0800 Subject: Instrumenting Erlang code In-Reply-To: <1364287934.20043536.1580064079923@mail.yahoo.com> References: <9cf863a2-8c61-3771-8e57-1499b660db43@gmail.com> <1364287934.20043536.1580064079923@mail.yahoo.com> Message-ID: <8460e7cb-d231-a5dd-ac0e-101847516d7b@gmail.com> On 1/26/20 10:41 AM, Vans S wrote: > On this topic, is there a way to attach instrumentation on the fly in > a running system? That can give you a callback onentry and onexit? To > profile wall time and perhap do conditional matching / stack trace > inspection. To see which calls trigger the slow path for example. You could take a look at eprof to see how it works ( https://github.com/erlang/otp/blob/c15eb5fdf721afed280afdbe0fff37706eef979c/lib/tools/src/eprof.erl#L373 ).? The eprof approach relies on tracing, which is mutating global state, so it lacks referential transparency and seems best to avoid in production source code (not saying tracing shouldn't be used in production). Best Regards, Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.r.nohl@REDACTED Mon Jan 27 12:33:31 2020 From: attila.r.nohl@REDACTED (Attila Rajmund Nohl) Date: Mon, 27 Jan 2020 12:33:31 +0100 Subject: Instrumenting Erlang code In-Reply-To: References: Message-ID: Frank Muller ezt ?rta (id?pont: 2020. jan. 26., V, 13:58): > > Hi everyone > > I would like to implement a custom instrumentation module for my Erlang code. [...] > f2() -> > instrument:start(), > > receive -> > {msg1, M1} -> instrument:end(), M1; > {msg2, M2} -> instrument:end(), M2; > _ -> instrument:end(), f2() > end. > > Is that doable? My (not really thought out) idea is that you could use dbg to start a process that receives a messages when f2 is called and is returning. If instrument:start or instrument:end does not need to execute in the same process as f2, then it might work. From mikpelinux@REDACTED Mon Jan 27 14:22:00 2020 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Mon, 27 Jan 2020 14:22:00 +0100 Subject: linter/checker for single-threaded state via numbered variables? Message-ID: Since Erlang doesn't allow you to rebind a variable in a scope where it's already bound (that becomes a match instead), there is a convention of using numbered variables to denote successive "generations" of some object or state that's intended to be used in a single-threaded or linear way. For example: foo(X0) -> X1 = update(X0), case predicate(X1) of true -> X2 = another_update(X1), persist(X2); false -> persist(X1) end. Here, whenever X(N+1) becomes bound, X(N) should become unused, and it should be an error if X(N) did not become unused. A variation is that the "final" value is the one without a number suffix. Is there any Erlang linter or style checker that can perform these types of checks? -------------- next part -------------- An HTML attachment was scrubbed... URL: From elbrujohalcon@REDACTED Mon Jan 27 15:09:57 2020 From: elbrujohalcon@REDACTED (Fernando Benavides) Date: Mon, 27 Jan 2020 15:09:57 +0100 Subject: linter/checker for single-threaded state via numbered variables? In-Reply-To: References: Message-ID: This looks like a great rule to add to Elvis . Would you mind writing an issue for it here ? Or if you're brave enough, we also accept Pull Requests ;) Cheers! On Mon, Jan 27, 2020 at 2:22 PM Mikael Pettersson wrote: > Since Erlang doesn't allow you to rebind a variable in a scope where it's > already bound (that becomes a match instead), there is a convention of > using numbered variables to denote successive "generations" of some object > or state that's intended to be used in a single-threaded or linear way. > For example: > > foo(X0) -> > X1 = update(X0), > case predicate(X1) of > true -> > X2 = another_update(X1), > persist(X2); > false -> > persist(X1) > end. > > Here, whenever X(N+1) becomes bound, X(N) should become unused, and it > should be an error if X(N) did not become unused. A variation is that the > "final" value is the one without a number suffix. > > Is there any Erlang linter or style checker that can perform these types > of checks? > -- Brujo Benavides about.me/elbrujohalcon -------------- next part -------------- An HTML attachment was scrubbed... URL: From rtrlists@REDACTED Mon Jan 27 23:04:38 2020 From: rtrlists@REDACTED (Robert Raschke) Date: Mon, 27 Jan 2020 22:04:38 +0000 Subject: linter/checker for single-threaded state via numbered variables? In-Reply-To: References: Message-ID: On Mon, 27 Jan 2020 13:22 Mikael Pettersson, wrote: > Since Erlang doesn't allow you to rebind a variable in a scope where it's > already bound (that becomes a match instead), there is a convention of > using numbered variables to denote successive "generations" of some object > or state that's intended to be used in a single-threaded or linear way. > For example: > > foo(X0) -> > X1 = update(X0), > case predicate(X1) of > true -> > X2 = another_update(X1), > persist(X2); > false -> > persist(X1) > end. > > Here, whenever X(N+1) becomes bound, X(N) should become unused, and it > should be an error if X(N) did not become unused. A variation is that the > "final" value is the one without a number suffix. > > Is there any Erlang linter or style checker that can perform these types > of checks? > For what it's worth, I consider this practice a bad code smell. Using numbered names like that is lazy. Usually such code can be radically improved upon by using names that properly describe the values they represent. Very often doing this will start you on the path to simpler code that ends up not requiring this kind of incremental buildup of "stuff". Cheers, Robby -------------- next part -------------- An HTML attachment was scrubbed... URL: From ledest@REDACTED Mon Jan 27 23:40:25 2020 From: ledest@REDACTED (Led) Date: Tue, 28 Jan 2020 00:40:25 +0200 Subject: linter/checker for single-threaded state via numbered variables? In-Reply-To: References: Message-ID: Since Erlang doesn't allow you to rebind a variable in a scope where it's > already bound (that becomes a match instead), there is a convention of > using numbered variables to denote successive "generations" of some object > or state that's intended to be used in a single-threaded or linear way. > For example: > > foo(X0) -> > X1 = update(X0), > case predicate(X1) of > true -> > X2 = another_update(X1), > persist(X2); > false -> > persist(X1) > end. > > foo(X0) -> X = update(X0), persist(case predicate(X) of true -> another_update(X); false -> X end). Start to hate me:) > Here, whenever X(N+1) becomes bound, X(N) should become unused, and it > should be an error if X(N) did not become unused. A variation is that the > "final" value is the one without a number suffix. > > Is there any Erlang linter or style checker that can perform these types > of checks? > -- Led. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kostis@REDACTED Tue Jan 28 00:32:12 2020 From: kostis@REDACTED (Kostis Sagonas) Date: Tue, 28 Jan 2020 00:32:12 +0100 Subject: Instrumenting Erlang code In-Reply-To: References: Message-ID: On 1/26/20 1:58 PM, Frank Muller wrote: > @Kostis: does Concuerror (https://github.com/parapluu/Concuerror) use > this technique? Concuerror is an open-source project and its source files have, for the most part, pretty descriptive names: https://github.com/parapluu/Concuerror/blob/master/src/concuerror_instrumenter.erl As you can see, Concuerror does not do its transformation at the source level but at the level of Core Erlang instead. The instrumentation code is not so involved either. Hope this helps, Kostis From be.dmitry@REDACTED Tue Jan 28 01:22:59 2020 From: be.dmitry@REDACTED (Dmitry Belyaev) Date: Tue, 28 Jan 2020 11:22:59 +1100 Subject: wx:batch/1 on Windows 10 In-Reply-To: References: <6aaea33c-24a7-2f7f-0387-f887762f0c22@zxq9.com> <53df9f84-d099-9ba9-f3a5-5b95c6b8bb09@zxq9.com> Message-ID: <3648B64D-9900-45A0-BCE2-36EF489C174C@gmail.com> Maybe batch(Window, Fun) -> ok = wxWindow:freeze(Window), try Fun() after -> ok = wxWindow:thaw(Window) end. would be better On 26 January 2020 12:59:23 pm AEDT, zxq9 wrote: >On 2020/01/21 20:16, Dan Gudmundsson wrote: >> > One thing that have changed is wxWidgets version, i.e. upgrade >> from 2.8 >> > to 3.0.3 (soon to be 3.1 on windows), >> > but I don't know what is causing this, nor how where is should >be >> fixed >> > in the application code, >> >? ?wx wrapper or wxwidgets library. > >Hi, again. > >After confirming the behavior (and also finding that freeze/1, [make >stuff], thaw/1 doesn't work on Windows) someone in the SO Erlang >channel >found this bug that has been around forever and seems to apply only to >wxMSW: > >https://trac.wxwidgets.org/ticket/10748 > >The description is exactly the problem I see. Hopefully they'll get >this >cleared up. It is a very weird problem. I imagine I can create a >workaround, but will need a few hours to mess with it to figure out a >way. > >If they fix freeze/thaw on all platforms then a non-hacky >implementation >of batch/1 could be: > > > -spec batch(Window, Fun) -> Result > when Window :: wx:wx_object(), > Fun :: fun(), > Result :: term(). > > batch(Window, Fun) -> > ok = wxWindow:freeze(Window), > Result = Fun(), > ok = wxWindow:thaw(Window), > Result. > >Fingers crossed this is addressed in 3.1. > >-Craig -- Kind regards, Dmitry Belyaev -------------- next part -------------- An HTML attachment was scrubbed... URL: From zxq9@REDACTED Tue Jan 28 01:28:30 2020 From: zxq9@REDACTED (zxq9) Date: Tue, 28 Jan 2020 09:28:30 +0900 Subject: wx:batch/1 on Windows 10 In-Reply-To: <3648B64D-9900-45A0-BCE2-36EF489C174C@gmail.com> References: <6aaea33c-24a7-2f7f-0387-f887762f0c22@zxq9.com> <53df9f84-d099-9ba9-f3a5-5b95c6b8bb09@zxq9.com> <3648B64D-9900-45A0-BCE2-36EF489C174C@gmail.com> Message-ID: <47a6bbb3-5d56-da36-a717-01721174e7e6@zxq9.com> On 2020/01/28 9:22, Dmitry Belyaev wrote: > Maybe > > batch(Window, Fun) -> > ok = wxWindow:freeze(Window), > try > Fun() > after -> > ok = wxWindow:thaw(Window) > end. > > would be better What would be better about that? If there is a problem in the GUI update (Fun()) the last thing I want to have happen is the Erlang half sticking around. -Craig From be.dmitry@REDACTED Tue Jan 28 01:50:36 2020 From: be.dmitry@REDACTED (Dmitry Belyaev) Date: Tue, 28 Jan 2020 11:50:36 +1100 Subject: wx:batch/1 on Windows 10 In-Reply-To: <47a6bbb3-5d56-da36-a717-01721174e7e6@zxq9.com> References: <6aaea33c-24a7-2f7f-0387-f887762f0c22@zxq9.com> <53df9f84-d099-9ba9-f3a5-5b95c6b8bb09@zxq9.com> <3648B64D-9900-45A0-BCE2-36EF489C174C@gmail.com> <47a6bbb3-5d56-da36-a717-01721174e7e6@zxq9.com> Message-ID: <474E1338-FDFF-4557-9F70-1E9DE8010FCF@gmail.com> I just wanted to remind of error handling and assumed a completely frozen UI is worse than the UI with only some components added, especially in a generic 'batch'. I wasn't sure about your particular use case, so I added "maybe". On 28 January 2020 11:28:30 am AEDT, zxq9 wrote: >On 2020/01/28 9:22, Dmitry Belyaev wrote: >> Maybe >> >> batch(Window, Fun) -> >> ok = wxWindow:freeze(Window), >> try >> Fun() >> after -> >> ok = wxWindow:thaw(Window) >> end. >> >> would be better > >What would be better about that? If there is a problem in the GUI >update > (Fun()) the last thing I want to have happen is the Erlang half >sticking around. > >-Craig -- Kind regards, Dmitry Belyaev -------------- next part -------------- An HTML attachment was scrubbed... URL: From be.dmitry@REDACTED Tue Jan 28 02:14:55 2020 From: be.dmitry@REDACTED (Dmitry Belyaev) Date: Tue, 28 Jan 2020 12:14:55 +1100 Subject: linter/checker for single-threaded state via numbered variables? In-Reply-To: References: Message-ID: <6A7DC4E5-E805-4A31-8EC6-F8D65335F8A6@gmail.com> That's definitely an option, however name generation may be difficult in some cases. The one I always have problems with is filling cowboy response by calling a cascade of functions updating request structure progressively. I'm not sure if other developers prefer typing ReqWithHeaders, ReqWithContentType, ReqWithBody, ReqHalted to consecutive but otherwise meaningless numbers. On 28 January 2020 9:04:38 am AEDT, Robert Raschke wrote: >On Mon, 27 Jan 2020 13:22 Mikael Pettersson, >wrote: > >> Since Erlang doesn't allow you to rebind a variable in a scope where >it's >> already bound (that becomes a match instead), there is a convention >of >> using numbered variables to denote successive "generations" of some >object >> or state that's intended to be used in a single-threaded or linear >way. >> For example: >> >> foo(X0) -> >> X1 = update(X0), >> case predicate(X1) of >> true -> >> X2 = another_update(X1), >> persist(X2); >> false -> >> persist(X1) >> end. >> >> Here, whenever X(N+1) becomes bound, X(N) should become unused, and >it >> should be an error if X(N) did not become unused. A variation is >that the >> "final" value is the one without a number suffix. >> >> Is there any Erlang linter or style checker that can perform these >types >> of checks? >> > >For what it's worth, I consider this practice a bad code smell. Using >numbered names like that is lazy. Usually such code can be radically >improved upon by using names that properly describe the values they >represent. Very often doing this will start you on the path to simpler >code >that ends up not requiring this kind of incremental buildup of "stuff". > >Cheers, >Robby -- Kind regards, Dmitry Belyaev -------------- next part -------------- An HTML attachment was scrubbed... URL: From petergi@REDACTED Tue Jan 28 04:30:47 2020 From: petergi@REDACTED (Peter J Etheridge) Date: Tue, 28 Jan 2020 14:30:47 +1100 Subject: mnesia:transaction Message-ID: dear friends,i am trying to write a first record to mnesia. for; mnesia:transaction(F) debugger evaluates F to be #Fun yet, when i run; mnesia:info(). it shows;record_table with 0 records occupying 301 words of mem 2 transactions committed,2 aborted,the remainder all showing zeros. what might cause an mnesia:write/3 to abort ? thank you in advance,peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From raoknz@REDACTED Tue Jan 28 05:56:57 2020 From: raoknz@REDACTED (Richard O'Keefe) Date: Tue, 28 Jan 2020 17:56:57 +1300 Subject: linter/checker for single-threaded state via numbered variables? In-Reply-To: <6A7DC4E5-E805-4A31-8EC6-F8D65335F8A6@gmail.com> References: <6A7DC4E5-E805-4A31-8EC6-F8D65335F8A6@gmail.com> Message-ID: The S0 S1 ... Sn S convention ultimately derives from Prolog, where it was used for (ordered) positions in a sequence or for (ordered) states. In both cases, the variables had exactly the same (design-level) type. Common practice was to use grammar rules to suppress these variables entirely. (Just as common Haskell practice is to define and use combinators to hide "plumbing".) One option would be to use inlined higher-order functions to hide "plumbing" variables. Another option is to break functions where you have many such variables into smaller pieces. foo(X) -> persist(maybe_transform(update(X))). transform(X) -> case predicate(X) of true -> another_update(X) ; false -> X end. In F# you'd write something like fun foo x -> x |> update |> maybe_update |> persist;; although I feel that F# over-uses this idiom. One thing I'll say about the numbered variable approach is that you had better get your code structure right first time, because it is a pain to introduce extra steps, remove steps, or reorder steps. It can get quite hairy when you entangle multiple states of *two* "variables". Imperative updates make this *look* straightforward, but the tangled mess is still there. On Tue, 28 Jan 2020 at 14:15, Dmitry Belyaev wrote: > > That's definitely an option, however name generation may be difficult in some cases. > The one I always have problems with is filling cowboy response by calling a cascade of functions updating request structure progressively. I'm not sure if other developers prefer typing ReqWithHeaders, ReqWithContentType, ReqWithBody, ReqHalted to consecutive but otherwise meaningless numbers. > > On 28 January 2020 9:04:38 am AEDT, Robert Raschke wrote: >> >> >> >> On Mon, 27 Jan 2020 13:22 Mikael Pettersson, wrote: >>> >>> Since Erlang doesn't allow you to rebind a variable in a scope where it's already bound (that becomes a match instead), there is a convention of using numbered variables to denote successive "generations" of some object or state that's intended to be used in a single-threaded or linear way. For example: >>> >>> foo(X0) -> >>> X1 = update(X0), >>> case predicate(X1) of >>> true -> >>> X2 = another_update(X1), >>> persist(X2); >>> false -> >>> persist(X1) >>> end. >>> >>> Here, whenever X(N+1) becomes bound, X(N) should become unused, and it should be an error if X(N) did not become unused. A variation is that the "final" value is the one without a number suffix. >>> >>> Is there any Erlang linter or style checker that can perform these types of checks? >> >> >> For what it's worth, I consider this practice a bad code smell. Using numbered names like that is lazy. Usually such code can be radically improved upon by using names that properly describe the values they represent. Very often doing this will start you on the path to simpler code that ends up not requiring this kind of incremental buildup of "stuff". >> >> Cheers, >> Robby >> > > -- > Kind regards, > Dmitry Belyaev From aronisstav@REDACTED Tue Jan 28 09:59:58 2020 From: aronisstav@REDACTED (Stavros Aronis) Date: Tue, 28 Jan 2020 09:59:58 +0100 Subject: Instrumenting Erlang code In-Reply-To: References: Message-ID: > > @Kostis: does Concuerror (https://github.com/parapluu/Concuerror) use > this technique? > Concuerror's instrumenter does not really work in the way you need. It is instead doing the following things: * wraps every function call / apply into a call to an inspector function concuerror_inspect:inspect (this function does a simple runtime check using the process dictionary to decide whether a process is under Concuerror or not) * adds a similar inspector function to every receive statement The process dictionary trick used to decide which modules should have the instrumentation on and which not might be useful to you, if you want to instrument all modules but not affect all processes: if the process has a specific atom in its dictionary then instrumentation is on, otherwise not. Without thinking too much about it, if I wanted to implement your variant I'd write a parse transform or custom instrumenter that would just introduce a helper function for every function like this: Original: f1() -> Body1. Becomes: f1() -> instrument:start(), R = f1_orig(), instrument:stop(), R fi_orig() -> Body1. Hope this helps! Stavros -------------- next part -------------- An HTML attachment was scrubbed... URL: From otp@REDACTED Tue Jan 28 11:12:46 2020 From: otp@REDACTED (Erlang/OTP) Date: Tue, 28 Jan 2020 11:12:46 +0100 (CET) Subject: Patch Package OTP 22.2.4 Released Message-ID: <20200128101246.3B2AD2547A8@hel.cslab.ericsson.net> Patch Package: OTP 22.2.4 Git Tag: OTP-22.2.4 Date: 2020-01-28 Trouble Report Id: OTP-16413, OTP-16424, OTP-16426 Seq num: ERL-1136 System: OTP Release: 22 Application: ssl-9.5.3 Predecessor: OTP 22.2.3 Check out the git tag OTP-22.2.4, and build a full OTP system including documentation. Apply one or more applications from this build as patches to your installation using the 'otp_patch_apply' tool. For information on install requirements, see descriptions for each application version below. --------------------------------------------------------------------- --- ssl-9.5.3 ------------------------------------------------------- --------------------------------------------------------------------- The ssl-9.5.3 application can be applied independently of other applications on a full OTP 22 installation. --- Fixed Bugs and Malfunctions --- OTP-16413 Application(s): ssl Related Id(s): ERL-1136 Enhance error handling, all ALERTS shall be handled gracefully and not cause a crash. OTP-16424 Application(s): ssl Enhance alert logging, in some places the role indication of the alert origin was missing. So the log would say undefined instead of client or server. OTP-16426 Application(s): ssl Related Id(s): ERL-1136 Two different optimizations did not work together and resulted in the possible breakage of connections using stream ciphers (that is RC4). Reworked the implementation to avoid this. Full runtime dependencies of ssl-9.5.3: crypto-4.2, erts-10.0, inets-5.10.7, kernel-6.0, public_key-1.5, stdlib-3.5 --------------------------------------------------------------------- --------------------------------------------------------------------- --------------------------------------------------------------------- From ebegumisa@REDACTED Wed Jan 29 11:30:34 2020 From: ebegumisa@REDACTED (Edmond Begumisa) Date: Wed, 29 Jan 2020 20:30:34 +1000 Subject: Instrumenting Erlang code In-Reply-To: References: Message-ID: Hi, Years ago, Tim Watson wrote a neat AOP-style library which uses function attributes to do just that... https://github.com/hyperthunk/annotations I haven't used it in a while, but I see the README was more recently updated so I presume it still works. - Edmond - On Sun, 26 Jan 2020 22:58:04 +1000, Frank Muller wrote: > Hi everyone > > I would like to implement a custom instrumentation module for my Erlang > code. > Let assume this function: > > f1() -> > ? code here ? > ok. > > When instrumenting this function, I would like it to look like: > > f1() -> > instrument:start(), > > ? code here ? > > instrument:end(), >> Other problem I can think of is when we have multiple return paths >> and/or recursive loop: > > f2() -> > instrument:start(), > > receive -> > {msg1, M1} -> instrument:end(), M1; > {msg2, M2} -> instrument:end(), M2; > _ -> instrument:end(), f2() > end. > > Is that doable? > If yes, can I apply like this logic to all modules running in my Erlang > node? > > @Kostis: does Concuerror (https://github.com/parapluu/Concuerror) use > this technique? > > Thanks for you help. > /Frank > > -- Using Opera's mail client: http://www.opera.com/mail/ From icfp.publicity@REDACTED Thu Jan 30 22:10:47 2020 From: icfp.publicity@REDACTED (Sam Tobin-Hochstadt) Date: Thu, 30 Jan 2020 16:10:47 -0500 Subject: Call for Papers: PACMPL issue ICFP 2020 Message-ID: <5e3346572d14e_7e7b2afcc21785b099050@homer.mail> PACMPL Volume 4, Issue ICFP 2020 Call for Papers accepted papers to be invited for presentation at The 25th ACM SIGPLAN International Conference on Functional Programming Jersey City, USA http://icfp20.sigplan.org/ ### Important dates Submissions due: 3 March 2020 (Tuesday) Anywhere on Earth https://icfp20.hotcrp.com Author response: 21 April (Tuesday) - 24 Apri (Friday) 14:00 UTC Notification: 8 May (Friday) Final copy due: 1 July (Wednesday) Conference: 18 August (Sunday) - 23 August (Friday) ### About PACMPL Proceedings of the ACM on Programming Languages (PACMPL ) is a Gold Open Access journal publishing research on all aspects of programming languages, from design to implementation and from mathematical formalisms to empirical studies. Each issue of the journal is devoted to a particular subject area within programming languages and will be announced through publicized Calls for Papers, like this one. ### Scope [PACMPL](https://pacmpl.acm.org/) issue ICFP 2020 seeks original papers on the art and science of functional programming. Submissions are invited on all topics from principles to practice, from foundations to features, and from abstraction to application. The scope includes all languages that encourage functional programming, including both purely applicative and imperative languages, as well as languages with objects, concurrency, or parallelism. Topics of interest include (but are not limited to): * Language Design: concurrency, parallelism, and distribution; modules; components and composition; metaprogramming; macros; pattern matching; type systems; type inference; dependent types; session types; gradual typing; refinement types; interoperability; domain-specific languages; imperative programming; object-oriented programming; logic programming; probabilistic programming; reactive programming; generic programming; bidirectional programming. * Implementation: abstract machines; virtual machines; interpretation; compilation; compile-time and run-time optimization; garbage collection and memory management; runtime systems; multi-threading; exploiting parallel hardware; interfaces to foreign functions, services, components, or low-level machine resources. * Software-Development Techniques: algorithms and data structures; design patterns; specification; verification; validation; proof assistants; debugging; testing; tracing; profiling; build systems; program synthesis. * Foundations: formal semantics; lambda calculus; program equivalence; rewriting; type theory; logic; category theory; monads; continuations; control; state; effects; names and binding; program verification. * Analysis and Transformation: control flow; data flow; abstract interpretation; partial evaluation; program calculation. * Applications: symbolic computing; formal-methods tools; artificial intelligence; systems programming; distributed systems and web programming; hardware design; databases; XML processing; scientific and numerical computing; graphical user interfaces; graphics and multimedia; GPU programming; scripting; system administration; security. * Education: teaching introductory programming; parallel programming; mathematical proof; algebra. Submissions will be evaluated according to their relevance, correctness, significance, originality, and clarity. Each submission should explain its contributions in both general and technical terms, clearly identifying what has been accomplished, explaining why it is significant, and comparing it with previous work. The technical content should be accessible to a broad audience. PACMPL issue ICFP 2020 also welcomes submissions in two separate categories ? Functional Pearls and Experience Reports ? that must be marked as such when submitted and that need not report original research results. Detailed guidelines on both categories are given at the end of this call. Please contact the principal editor if you have questions or are concerned about the appropriateness of a topic. ### Preparation of submissions **Deadline**: The deadline for submissions is **Tuesday, March 3, 2020**, Anywhere on Earth (). This deadline will be strictly enforced. **Formatting**: Submissions must be in PDF format, printable in black and white on US Letter sized paper, and interpretable by common PDF tools. All submissions must adhere to the "ACM Small" template that is available (in both LaTeX and Word formats) from . For authors using LaTeX, a lighter-weight package, including only the essential files, is available from . There is a limit of **25 pages for a full paper or Functional Pearl** and **12 pages for an Experience Report**; in either case, the bibliography will not be counted against these limits. Submissions that exceed the page limits or, for other reasons, do not meet the requirements for formatting, will be summarily rejected. Supplementary material can and should be **separately** submitted (see below). See also PACMPL's Information and Guidelines for Authors at . **Submission**: Submissions will be accepted at Improved versions of a paper may be submitted at any point before the submission deadline using the same web interface. **Author Response Period**: Authors will have a 72-hour period, starting at 14:00 UTC on **Tuesday, April 21, 2020**, to read reviews and respond to them. **Supplementary Material**: Authors have the option to attach supplementary material to a submission, on the understanding that reviewers may choose not to look at it. This supplementary material should **not** be submitted as part of the main document; instead, it should be uploaded as a **separate** PDF document or tarball. Supplementary material should be uploaded **at submission time**, not by providing a URL in the paper that points to an external repository. Authors are free to upload both anonymized and non-anonymized supplementary material. Anonymized supplementary material will be visible to reviewers immediately; non-anonymized supplementary material will be revealed to reviewers only after they have submitted their review of the paper and learned the identity of the author(s). **Authorship Policies**: All submissions are expected to comply with the ACM Policies for Authorship that are detailed at . **Republication Policies**: Each submission must adhere to SIGPLAN's republication policy, as explained on the web at . ### Review Process This section outlines the two-stage process with lightweight double-blind reviewing that will be used to select papers for PACMPL issue ICFP 2020. We anticipate that there will be a need to clarify and expand on this process, and we will maintain a list of frequently asked questions and answers on the conference website to address common concerns. **PACMPL issue ICFP 2020 will employ a two-stage review process.** The first stage in the review process will assess submitted papers using the criteria stated above and will allow for feedback and input on initial reviews through the author response period mentioned previously. At the review meeting, a set of papers will be conditionally accepted and all other papers will be rejected. Authors will be notified of these decisions on **May 8, 2020**. Authors of conditionally accepted papers will be provided with committee reviews (just as in previous conferences) along with a set of mandatory revisions. After four weeks (June 5, 2020), the authors will provide a second submission. The second and final reviewing phase assesses whether the mandatory revisions have been adequately addressed by the authors and thereby determines the final accept/reject status of the paper. The intent and expectation is that the mandatory revisions can be addressed within four weeks and hence that conditionally accepted papers will in general be accepted in the second phase. The second submission should clearly identify how the mandatory revisions were addressed. To that end, the second submission must be accompanied by a cover letter mapping each mandatory revision request to specific parts of the paper. The cover letter will facilitate a quick second review, allowing for confirmation of final acceptance within two weeks. Conversely, the absence of a cover letter will be grounds for the paper?s rejection. **PACMPL issue ICFP 2020 will employ a lightweight double-blind reviewing process.** To facilitate this, submitted papers must adhere to two rules: 1. **author names and institutions must be omitted**, and 2. **references to authors' own related work should be in the third person** (e.g., not "We build on our previous work ..." but rather "We build on the work of ..."). The purpose of this process is to help the reviewers come to an initial judgement about the paper without bias, not to make it impossible for them to discover the authors if they were to try. Nothing should be done in the name of anonymity that weakens the submission or makes the job of reviewing the paper more difficult (e.g., important background references should not be omitted or anonymized). In addition, authors should feel free to disseminate their ideas or draft versions of their paper as they normally would. For instance, authors may post drafts of their papers on the web or give talks on their research ideas. ### Information for Authors of Accepted Papers * As a condition of acceptance, final versions of all papers must adhere to the new ACM Small format. The page limit for the final versions of papers will be increased by two pages to help authors respond to reviewer comments and mandatory revisions: **27 pages plus bibliography for a regular paper or Functional Pearl, 14 pages plus bibliography for an Experience Report**. * Authors of accepted submissions will be required to agree to one of the three ACM licensing options: open access on payment of a fee (**recommended**, and SIGPLAN can cover the cost as described next); copyright transfer to ACM; or retaining copyright but granting ACM exclusive publication rights. Further information about ACM author rights is available from . * PACMPL is a Gold Open Access journal. It will be archived in ACM?s Digital Library, but no membership or fee is required for access. Gold Open Access has been made possible by generous funding through ACM SIGPLAN, which will cover all open access costs in the event authors cannot. Authors who can cover the costs may do so by paying an Article Processing Charge (APC). PACMPL, SIGPLAN, and ACM Headquarters are committed to exploring routes to making Gold Open Access publication both affordable and sustainable. * ACM offers authors a range of copyright options, one of which is Creative Commons CC-BY publication; this is the option recommended by the PACMPL editorial board. A reasoned argument in favour of this option can be found in the article [Why CC-BY?](https://oaspa.org/why-cc-by/) published by OASPA, the Open Access Scholarly Publishers Association. * We intend that the papers will be freely available for download from the ACM Digital Library in perpetuity via the OpenTOC mechanism. * ACM Author-Izer is a unique service that enables ACM authors to generate and post links on either their home page or institutional repository for visitors to download the definitive version of their articles from the ACM Digital Library at no charge. Downloads through Author-Izer links are captured in official ACM statistics, improving the accuracy of usage and impact measurements. Consistently linking to the definitive version of an ACM article should reduce user confusion over article versioning. After an article has been published and assigned to the appropriate ACM Author Profile pages, authors should visit to learn how to create links for free downloads from the ACM DL. * The official publication date is the date the papers are made available in the ACM Digital Library. This date may be up to *two weeks prior* to the first day of the conference. The official publication date affects the deadline for any patent filings related to published work. * At least one author of each accepted submission will be expected to attend and present that paper at the conference. The schedule for presentations will be determined and shared with authors after the full program has been selected. Presentations will be videotaped and released online if the presenter consents. In extraordinary circumstances, at the discretion of the principal editor, alternative presentation methods may be approved for specific papers. The canonical example is where all authors are denied visas to the ICFP host country, in which case a nonauthor may be deputized to present, or various electronic substitutes may be considered. We list these options in the interest of transparency, but please keep in mind that, most years, no exceptions are granted. This option is not meant, e.g., to excuse cases where authors find themselves double-booked with other meetings (so, at the time of submitting a paper, please do keep the days of the conference reserved on at least one author?s calendar). ### Artifact Evaluation Authors of papers that are conditionally accepted in the first phase of the review process will be encouraged (but not required) to submit supporting materials for Artifact Evaluation. These items will then be reviewed by an Artifact Evaluation Committee, separate from the paper Review Committee, whose task is to assess how the artifacts support the work described in the associated paper. Papers that go through the Artifact Evaluation process successfully will receive a seal of approval printed on the papers themselves. Authors of accepted papers will be encouraged to make the supporting materials publicly available upon publication of the papers, for example, by including them as "source materials" in the ACM Digital Library. An additional seal will mark papers whose artifacts are made available, as outlined in the ACM guidelines for artifact badging. Participation in Artifact Evaluation is voluntary and will not influence the final decision regarding paper acceptance. ### Special categories of papers In addition to research papers, PACMPL issue ICFP solicits two kinds of papers that do not require original research contributions: Functional Pearls, which are full papers, and Experience Reports, which are limited to half the length of a full paper. Authors submitting such papers should consider the following guidelines. #### Functional Pearls A Functional Pearl is an elegant essay about something related to functional programming. Examples include, but are not limited to: * a new and thought-provoking way of looking at an old idea * an instructive example of program calculation or proof * a nifty presentation of an old or new data structure * an interesting application of functional programming techniques * a novel use or exposition of functional programming in the classroom While pearls often demonstrate an idea through the development of a short program, there is no requirement or expectation that they do so. Thus, they encompass the notions of theoretical and educational pearls. Functional Pearls are valued as highly and judged as rigorously as ordinary papers, but using somewhat different criteria. In particular, a pearl is not required to report original research, but, it should be concise, instructive, and entertaining. A pearl is likely to be rejected if its readers get bored, if the material gets too complicated, if too much specialized knowledge is needed, or if the writing is inelegant. The key to writing a good pearl is polishing. A submission that is intended to be treated as a pearl must be marked as such on the submission web page, and should contain the words "Functional Pearl" somewhere in its title or subtitle. These steps will alert reviewers to use the appropriate evaluation criteria. Pearls will be combined with ordinary papers, however, for the purpose of computing the conference's acceptance rate. #### Experience Reports The purpose of an Experience Report is to help create a body of published, refereed, citable evidence that functional programming really works -- or to describe what obstacles prevent it from working. Possible topics for an Experience Report include, but are not limited to: * insights gained from real-world projects using functional programming * comparison of functional programming with conventional programming in the context of an industrial project or a university curriculum * project-management, business, or legal issues encountered when using functional programming in a real-world project * curricular issues encountered when using functional programming in education * real-world constraints that created special challenges for an implementation of a functional language or for functional programming in general An Experience Report is distinguished from a normal PACMPL issue ICFP paper by its title, by its length, and by the criteria used to evaluate it. * Both in the papers and in any citations, the title of each accepted Experience Report must end with the words "(Experience Report)" in parentheses. The acceptance rate for Experience Reports will be computed and reported separately from the rate for ordinary papers. * Experience Report submissions can be at most 12 pages long, excluding bibliography. * Each accepted Experience Report will be presented at the conference, but depending on the number of Experience Reports and regular papers accepted, authors of Experience reports may be asked to give shorter talks. * Because the purpose of Experience Reports is to enable our community to accumulate a body of evidence about the efficacy of functional programming, an acceptable Experience Report need not add to the body of knowledge of the functional-programming community by presenting novel results or conclusions. It is sufficient if the Report states a clear thesis and provides supporting evidence. The thesis must be relevant to ICFP, but it need not be novel. The review committee will accept or reject Experience Reports based on whether they judge the evidence to be convincing. Anecdotal evidence will be acceptable provided it is well argued and the author explains what efforts were made to gather as much evidence as possible. Typically, more convincing evidence is obtained from papers which show how functional programming was used than from papers which only say that functional programming was used. The most convincing evidence often includes comparisons of situations before and after the introduction or discontinuation of functional programming. Evidence drawn from a single person's experience may be sufficient, but more weight will be given to evidence drawn from the experience of groups of people. An Experience Report should be short and to the point: it should make a claim about how well functional programming worked on a particular project and why, and produce evidence to substantiate this claim. If functional programming worked in this case in the same ways it has worked for others, the paper need only summarize the results — the main part of the paper should discuss how well it worked and in what context. Most readers will not want to know all the details of the project and its implementation, but the paper should characterize the project and its context well enough so that readers can judge to what degree this experience is relevant to their own projects. The paper should take care to highlight any unusual aspects of the project. Specifics about the project are more valuable than generalities about functional programming; for example, it is more valuable to say that the team delivered its software a month ahead of schedule than it is to say that functional programming made the team more productive. If the paper not only describes experience but also presents new technical results, or if the experience refutes cherished beliefs of the functional-programming community, it may be better to submit it as a full paper, which will be judged by the usual criteria of novelty, originality, and relevance. The principal editor will be happy to advise on any concerns about which category to submit to. ### ICFP Organizers General Chair: Stephanie Weirich (University of Pennsylvania, USA) Artifact Evaluation Co-Chairs: Ben Lippmeier (UNSW, Australia) Brent Yorgey (Hendrix College, USA) Industrial Relations Chair: Alan Jeffrey (Mozilla Research, USA) Programming Contest Organiser: Igor Lukanin (Kontur, Russia) Publicity and Web Chair: Sam Tobin-Hochstadt (Indiana University, USA) Student Research Competition Chair: Youyou Cong (Tokyo Institute of Technology, Japan) Workshops Co-Chair: Leonidas Lampropoulos (University of Maryland, USA) Jennifer Hackett (University of Nottingham, UK) Conference Manager: Annabel Satin (P.C.K.) ### PACMPL Volume 4, Issue ICFP 2020 Principal Editor: Adam Chlipala (MIT, USA) Review Committee: Andreas Abel (Gothenburg University, Sweden) Nada Amin (Harvard University, USA) Edwin Brady (University of St. Andrews, UK) William E. Byrd (University of Alabama at Birmingham, USA) David Darais (University of Vermont) Richard A. Eisenberg (Bryn Mawr College, USA) Matthew Fluet (Rochester Institute of Technology, USA) Makoto Hamana (Gunma University, Japan) Fritz Henglein (Department of Computer Science, University of Copenhagen (DIKU) and Deon Digital, Denmark) Jan Hoffmann (Carnegie Mellon University, USA) Robbert Krebbers (Delft University of Technology, Netherlands) Neel Krishnaswami (Computer Laboratory, University of Cambridge, UK) Geoffrey Mainland (Drexel University, USA) Magnus O. Myreen (Chalmers University of Technology, Sweden) Atsushi Ohori (Tohoku University, Japan) Frank Piessens (KU Leuven, Belgium) Nadia Polikarpova (University of California San Diego, USA) Jonathan Protzenko (Microsoft Research, USA) Jerome Simeon (Clause, France) KC Sivaramakrishnan (IIT Madras, India) External Review Committee: Danel Ahman (University of Ljubljana, Slovenia) Aws Albarghouthi (University of Wisconsin-Madison, USA) Kenichi Asai (Ochanomizu University, Japan) Patrick Bahr (IT University of Copenhagen, Denmark) Stephanie Balzer (Carnegie Mellon University, USA) Jean-Philippe Bernardy (University of Gothenburg, Sweden) Sandrine Blazy (Univ Rennes-IRISA, France) Benjamin Canou (OCamlPro, France) Giuseppe Castagna (CNRS - Universit? de Paris, France) Jesper Cockx (TU Delft, Netherlands) Youyou Cong (Tokyo Institute of Technology, Japan) Leonardo De Moura (Microsoft Research, USA) Sebastian Erdweg (JGU Mainz, Germany) Ronald Garcia (University of British Columbia, Canada) Jennifer Hackett (University of Nottingham, UK) Troels Henriksen (University of Copenhagen, Denmark) Gabriele Keller (Utrecht University, Netherlands) Delia Kesner (IRIF, France / University of Paris Diderot, France) Shriram Krishnamurthi (Brown University, United States) Jan Midtgaard (University of Southern Denmark, Denmark) Andrey Mokhov (Jane Street, USA) J. Garrett Morris (University of Kansas, USA) Stefan Muller (Carnegie Mellon University, USA) Rasmus Ejlers M?gelberg (IT University of Copenhagen, Denmark) Cyrus Omar (University of Chicago, USA) Dominic Orchard (University of Kent, UK) Ivan Perez (NIA / NASA Formal Methods) Brigitte Pientka (McGill University, Canada) Juan Pedro Bol?var Puente (Independent Consultant, Sinusoidal Engineering) Norman Ramsey (Tufts University, USA) Christine Rizkallah (UNSW Sydney, Australia) Tiark Rompf (Purdue University, USA) Guido Salvaneschi (Technische Universit?t Darmstadt, Germany) Tom Schrijvers (KU Leuven, Belgium) Chung-chieh Shan (Indiana University, USA) Vincent St-Amour (Northwestern University, USA) Aaron Stump (The University of Iowa, USA) Nicolas Tabareau (Inria, France) Ross Tate (Cornell University, USA) Dimitrios Vytiniotis (DeepMind, UK) John Wiegley (DFINITY, USA) Beta Ziliani (FAMAF, UNC and CONICET, Argentina) From matthias@REDACTED Thu Jan 30 22:55:40 2020 From: matthias@REDACTED (Matthias Lang) Date: Thu, 30 Jan 2020 22:55:40 +0100 Subject: does anyone know what Nordnet are doing with Erlang? Message-ID: <20200130215539.GB3479@hec.corelatus.se> Hi, Does anyone know a bit about the history of Erlang at Nordnet? Nordnet is a Swedish online bank. A few years ago, I noticed that they had a short Erlang example for their API: https://api.test.nordnet.se/projects/api/wiki/Erlang_example More recently, I noticed that they were looking for an "Erlang Developer with Java experience", unclear in which city. A few years back, the CTO wrote a blog post which includes "The tech dimension is pretty straight forward with a nice and easy Erlang implementation" https://blogg.nordnet.se/it-challenges-according-to-cto-part-2/ They don't seem to have anything to do with Klarna (well-known Erlang users). About the only connection I can find is a short reference that a previous CTO, Klas Ljungkvist, started off at Ericsson. Matthias From v@REDACTED Fri Jan 31 15:17:16 2020 From: v@REDACTED (Valentin Micic) Date: Fri, 31 Jan 2020 16:17:16 +0200 Subject: Orber Message-ID: Hi, I remember that Order has been discontinued quite a while ago, but I would like to know if anyone is still using it, and if so, does anyone use with newer Erlang versions versions, say R21 and above? Tanks in advance. V/ From v@REDACTED Fri Jan 31 15:30:31 2020 From: v@REDACTED (Valentin Micic) Date: Fri, 31 Jan 2020 16:30:31 +0200 Subject: Orber In-Reply-To: References: Message-ID: <6C094268-5216-4FDE-8298-C4BDEDF13033@micic.co.za> My sincere apology, it appears that I?ve mistyped ? I meant to say: ORBER (Erlang Version of CORBA). > On 31 Jan 2020, at 16:17, Valentin Micic wrote: > > Hi, > > I remember that Order has been discontinued quite a while ago, but I would like to know if anyone is still using it, and if so, does anyone use with newer Erlang versions versions, say R21 and above? > > Tanks in advance. > > V/ > From dangud@REDACTED Fri Jan 31 15:56:01 2020 From: dangud@REDACTED (Dan Gudmundsson) Date: Fri, 31 Jan 2020 15:56:01 +0100 Subject: Orber In-Reply-To: <6C094268-5216-4FDE-8298-C4BDEDF13033@micic.co.za> References: <6C094268-5216-4FDE-8298-C4BDEDF13033@micic.co.za> Message-ID: It can be found here: https://github.com/erlang/corba and should work with OTP-22. On Fri, Jan 31, 2020 at 3:30 PM Valentin Micic wrote: > My sincere apology, it appears that I?ve mistyped ? I meant to say: ORBER > (Erlang Version of CORBA). > > > > On 31 Jan 2020, at 16:17, Valentin Micic wrote: > > > > Hi, > > > > I remember that Order has been discontinued quite a while ago, but I > would like to know if anyone is still using it, and if so, does anyone use > with newer Erlang versions versions, say R21 and above? > > > > Tanks in advance. > > > > V/ > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From v@REDACTED Fri Jan 31 16:14:51 2020 From: v@REDACTED (Valentin Micic) Date: Fri, 31 Jan 2020 17:14:51 +0200 Subject: Orber In-Reply-To: References: <6C094268-5216-4FDE-8298-C4BDEDF13033@micic.co.za> Message-ID: Hey Dan, Thank you very much! > On 31 Jan 2020, at 16:56, Dan Gudmundsson wrote: > > It can be found here: https://github.com/erlang/corba > and should work with OTP-22. > > On Fri, Jan 31, 2020 at 3:30 PM Valentin Micic > wrote: > My sincere apology, it appears that I?ve mistyped ? I meant to say: ORBER (Erlang Version of CORBA). > > > > On 31 Jan 2020, at 16:17, Valentin Micic > wrote: > > > > Hi, > > > > I remember that Order has been discontinued quite a while ago, but I would like to know if anyone is still using it, and if so, does anyone use with newer Erlang versions versions, say R21 and above? > > > > Tanks in advance. > > > > V/ > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.levytskyy@REDACTED Fri Jan 31 19:21:46 2020 From: v.levytskyy@REDACTED (Vyacheslav Levytskyy) Date: Fri, 31 Jan 2020 19:21:46 +0100 Subject: memory used by Erlang VM In-Reply-To: References: Message-ID: <6737be5b-fef2-7f1c-7833-7300ac79d14f@yahoo.com> Hello, I wonder why memory used by Erlang VM as reported by the kernel via the /proc/pid differs from erlang:memory(total). In my current configuration I observe realistic response from erlang:memory(total) and much lower values from the /proc/pid. I'm not surprised by the difference itself, but rather by the fact that the /proc/pid gives unrealistically lower values -- I'm not 100% sure, but it looks like RabbitMQ is using the /proc/pid approach by default, proposing also recon_alloc:memory(allocated) and erlang:memory(total) as available options of Erlang VM memory consumption calculation strategy. Does anybody have insights of what and why is going on with those calculations of memory used by Erlang VM? Is it possible to select one strategy beforehand for my Erlang app, or I must measure on each new configuration what looks more precise? Should I compare and change the strategy during run-time, or after I selected a strategy once for my configuration I can be sure that selected approach always better than other two? Thank you, Vyacheslav From jesper.louis.andersen@REDACTED Fri Jan 31 19:59:51 2020 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Fri, 31 Jan 2020 19:59:51 +0100 Subject: memory used by Erlang VM In-Reply-To: <6737be5b-fef2-7f1c-7833-7300ac79d14f@yahoo.com> References: <6737be5b-fef2-7f1c-7833-7300ac79d14f@yahoo.com> Message-ID: When you say /proc/pid, what are you looking at specifically in there? It is a bit different depending on which Unix you run on, so a simple example will help a lot. In particular, my early guess is going to be virtual memory vs physical RSS mapping. The former can be much higher than the latter. Especially in system such as Linux, which allow overcommitting memory. On Fri, Jan 31, 2020 at 7:22 PM Vyacheslav Levytskyy wrote: > Hello, > > I wonder why memory used by Erlang VM as reported by the kernel via the > /proc/pid differs from erlang:memory(total). In my current configuration > I observe realistic response from erlang:memory(total) and much lower > values from the /proc/pid. > > I'm not surprised by the difference itself, but rather by the fact that > the /proc/pid gives unrealistically lower values -- I'm not 100% sure, > but it looks like RabbitMQ is using the /proc/pid approach by default, > proposing also recon_alloc:memory(allocated) and erlang:memory(total) as > available options of Erlang VM memory consumption calculation strategy. > > Does anybody have insights of what and why is going on with those > calculations of memory used by Erlang VM? Is it possible to select one > strategy beforehand for my Erlang app, or I must measure on each new > configuration what looks more precise? Should I compare and change the > strategy during run-time, or after I selected a strategy once for my > configuration I can be sure that selected approach always better than > other two? > > Thank you, > Vyacheslav > -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.levytskyy@REDACTED Fri Jan 31 20:23:27 2020 From: v.levytskyy@REDACTED (Vyacheslav Levytskyy) Date: Fri, 31 Jan 2020 20:23:27 +0100 Subject: memory used by Erlang VM In-Reply-To: References: <6737be5b-fef2-7f1c-7833-7300ac79d14f@yahoo.com> Message-ID: It's linux (ubuntu). I read /proc/[pid]/statm, take RSS number of pages (the 2nd value in the line of that file) and calculate memory used by Erlang VM as RSS x page size (read as "getconf PAGESIZE"). On 31.01.2020 19:59, Jesper Louis Andersen wrote: > When you say /proc/pid, what are you looking at specifically in there? > It is a bit different?depending on which Unix you run on, so a simple > example?will help a lot. > > In particular, my early guess is going to be virtual memory vs > physical RSS mapping. The former can be much higher than the latter. > Especially in system such as Linux, which allow overcommitting memory. > > On Fri, Jan 31, 2020 at 7:22 PM Vyacheslav Levytskyy > > wrote: > > Hello, > > I wonder why memory used by Erlang VM as reported by the kernel > via the > /proc/pid differs from erlang:memory(total). In my current > configuration > I observe realistic response from erlang:memory(total) and much lower > values from the /proc/pid. > > I'm not surprised by the difference itself, but rather by the fact > that > the /proc/pid gives unrealistically lower values -- I'm not 100% > sure, > but it looks like RabbitMQ is using the /proc/pid approach by > default, > proposing also recon_alloc:memory(allocated) and > erlang:memory(total) as > available options of Erlang VM memory consumption calculation > strategy. > > Does anybody have insights of what and why is going on with those > calculations of memory used by Erlang VM? Is it possible to select > one > strategy beforehand for my Erlang app, or I must measure on each new > configuration what looks more precise? Should I compare and change > the > strategy during run-time, or after I selected a strategy once for my > configuration I can be sure that selected approach always better than > other two? > > Thank you, > Vyacheslav > > > > -- > J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.levytskyy@REDACTED Fri Jan 31 20:23:27 2020 From: v.levytskyy@REDACTED (Vyacheslav Levytskyy) Date: Fri, 31 Jan 2020 20:23:27 +0100 Subject: memory used by Erlang VM In-Reply-To: References: <6737be5b-fef2-7f1c-7833-7300ac79d14f@yahoo.com> Message-ID: It's linux (ubuntu). I read /proc/[pid]/statm, take RSS number of pages (the 2nd value in the line of that file) and calculate memory used by Erlang VM as RSS x page size (read as "getconf PAGESIZE"). On 31.01.2020 19:59, Jesper Louis Andersen wrote: > When you say /proc/pid, what are you looking at specifically in there? > It is a bit different?depending on which Unix you run on, so a simple > example?will help a lot. > > In particular, my early guess is going to be virtual memory vs > physical RSS mapping. The former can be much higher than the latter. > Especially in system such as Linux, which allow overcommitting memory. > > On Fri, Jan 31, 2020 at 7:22 PM Vyacheslav Levytskyy > > wrote: > > Hello, > > I wonder why memory used by Erlang VM as reported by the kernel > via the > /proc/pid differs from erlang:memory(total). In my current > configuration > I observe realistic response from erlang:memory(total) and much lower > values from the /proc/pid. > > I'm not surprised by the difference itself, but rather by the fact > that > the /proc/pid gives unrealistically lower values -- I'm not 100% > sure, > but it looks like RabbitMQ is using the /proc/pid approach by > default, > proposing also recon_alloc:memory(allocated) and > erlang:memory(total) as > available options of Erlang VM memory consumption calculation > strategy. > > Does anybody have insights of what and why is going on with those > calculations of memory used by Erlang VM? Is it possible to select > one > strategy beforehand for my Erlang app, or I must measure on each new > configuration what looks more precise? Should I compare and change > the > strategy during run-time, or after I selected a strategy once for my > configuration I can be sure that selected approach always better than > other two? > > Thank you, > Vyacheslav > > > > -- > J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.levytskyy@REDACTED Fri Jan 31 20:44:02 2020 From: v.levytskyy@REDACTED (Vyacheslav Levytskyy) Date: Fri, 31 Jan 2020 20:44:02 +0100 Subject: memory used by Erlang VM In-Reply-To: References: <6737be5b-fef2-7f1c-7833-7300ac79d14f@yahoo.com> Message-ID: I have also zero swappiness: cat /proc/sys/vm/swappiness 0 so I expect that RSS shows total memory used. On 31.01.2020 20:23, Vyacheslav Levytskyy wrote: > > It's linux (ubuntu). I read /proc/[pid]/statm, take RSS number of > pages (the 2nd value in the line of that file) and calculate memory > used by Erlang VM as RSS x page size (read as "getconf PAGESIZE"). > > On 31.01.2020 19:59, Jesper Louis Andersen wrote: >> When you say /proc/pid, what are you looking at specifically in >> there? It is a bit different?depending on which Unix you run on, so a >> simple example?will help a lot. >> >> In particular, my early guess is going to be virtual memory vs >> physical RSS mapping. The former can be much higher than the latter. >> Especially in system such as Linux, which allow overcommitting memory. >> >> On Fri, Jan 31, 2020 at 7:22 PM Vyacheslav Levytskyy >> > wrote: >> >> Hello, >> >> I wonder why memory used by Erlang VM as reported by the kernel >> via the >> /proc/pid differs from erlang:memory(total). In my current >> configuration >> I observe realistic response from erlang:memory(total) and much >> lower >> values from the /proc/pid. >> >> I'm not surprised by the difference itself, but rather by the >> fact that >> the /proc/pid gives unrealistically lower values -- I'm not 100% >> sure, >> but it looks like RabbitMQ is using the /proc/pid approach by >> default, >> proposing also recon_alloc:memory(allocated) and >> erlang:memory(total) as >> available options of Erlang VM memory consumption calculation >> strategy. >> >> Does anybody have insights of what and why is going on with those >> calculations of memory used by Erlang VM? Is it possible to >> select one >> strategy beforehand for my Erlang app, or I must measure on each new >> configuration what looks more precise? Should I compare and >> change the >> strategy during run-time, or after I selected a strategy once for my >> configuration I can be sure that selected approach always better >> than >> other two? >> >> Thank you, >> Vyacheslav >> >> >> >> -- >> J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerhard@REDACTED Fri Jan 31 21:14:58 2020 From: gerhard@REDACTED (Gerhard Lazu) Date: Fri, 31 Jan 2020 20:14:58 +0000 Subject: memory used by Erlang VM In-Reply-To: References: <6737be5b-fef2-7f1c-7833-7300ac79d14f@yahoo.com> Message-ID: I remember that battle with Erlang vs OS memory reporting well, it was such a show. This captures my thinking from 2017: https://github.com/rabbitmq/rabbitmq-server/issues/1223 . This has more context: https://github.com/rabbitmq/rabbitmq-server/pull/1259#issuecomment-308428057. There are a few other comments in that thread that you may find useful. Erlang will either over-report or under-report the memory used. erlang:memory(total) will very rarely match the physical RSS mapping, as explained earlier by Jesper + https://stackoverflow.com/questions/7880784/what-is-rss-and-vsz-in-linux-memory-management. This detailed snapshot of Erlang memory allocators state shows this in the clearest way that I am aware of: https://grafana.gcp.rabbitmq.com/dashboard/snapshot/wM5JcgR9oQToU4CR54IbOq1NtAsa6jvu As it stands, the Linux OOM takes action based on the RSS value. While from an Erlang perspective it may seem OK to ask the OS for more memory, we've had years of poor RabbitMQ experience when the Erlang VM process would get killed by the Linux OOM because it was asking for memory that the system didn't have available. This has more information: https://www.rabbitmq.com/memory-use.html Hope this helps, Gerhard. On Fri, Jan 31, 2020 at 7:00 PM Jesper Louis Andersen < jesper.louis.andersen@REDACTED> wrote: > When you say /proc/pid, what are you looking at specifically in there? It > is a bit different depending on which Unix you run on, so a simple > example will help a lot. > > In particular, my early guess is going to be virtual memory vs physical > RSS mapping. The former can be much higher than the latter. Especially in > system such as Linux, which allow overcommitting memory. > > On Fri, Jan 31, 2020 at 7:22 PM Vyacheslav Levytskyy < > v.levytskyy@REDACTED> wrote: > >> Hello, >> >> I wonder why memory used by Erlang VM as reported by the kernel via the >> /proc/pid differs from erlang:memory(total). In my current configuration >> I observe realistic response from erlang:memory(total) and much lower >> values from the /proc/pid. >> >> I'm not surprised by the difference itself, but rather by the fact that >> the /proc/pid gives unrealistically lower values -- I'm not 100% sure, >> but it looks like RabbitMQ is using the /proc/pid approach by default, >> proposing also recon_alloc:memory(allocated) and erlang:memory(total) as >> available options of Erlang VM memory consumption calculation strategy. >> >> Does anybody have insights of what and why is going on with those >> calculations of memory used by Erlang VM? Is it possible to select one >> strategy beforehand for my Erlang app, or I must measure on each new >> configuration what looks more precise? Should I compare and change the >> strategy during run-time, or after I selected a strategy once for my >> configuration I can be sure that selected approach always better than >> other two? >> >> Thank you, >> Vyacheslav >> > > > -- > J. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Fri Jan 31 21:27:02 2020 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Fri, 31 Jan 2020 21:27:02 +0100 Subject: memory used by Erlang VM In-Reply-To: References: <6737be5b-fef2-7f1c-7833-7300ac79d14f@yahoo.com> Message-ID: It is expected your RSS value is lower than what Erlang reports. Erlang requests virtual memory from the operating system (Linux). But it is mapped into the process on-demand. RSS is the resident set size, which is the currently physical mapped pages. As Erlang hits pages it hasn't used before, a kernel trap is generated and it maps in that page to to the process. For example, lets say we allocate a large array to hold processes, but we are only using a small smidgen of that array. Then there are many virtually mapped pages, but we aren't really "using" the memory yet. It is taken on-demand. This on-demand method is smart because it lowers memory pressure. Rather than having to do all the work up front, we can amortize the work over the course of the program running, which is much more efficient. If the application requests 1 gigabyte of memory say, and we want to give it right away, we must zero one gigabyte of memory. This takes time. But on-demand, we can keep a background process for zeroing memory and allocate it as it is needed, among other things. Where this can create a problem is if you have several processes all wanting lots of memory, and you have less memory in the machine than what they've got promised by the kernel. Then, if they all starts wanting memory, you should expect to see various trouble. As Erlang runs more, I would expect the RSS to go up as it populates more of the memory space. On Fri, Jan 31, 2020 at 8:23 PM Vyacheslav Levytskyy wrote: > It's linux (ubuntu). I read /proc/[pid]/statm, take RSS number of pages > (the 2nd value in the line of that file) and calculate memory used by > Erlang VM as RSS x page size (read as "getconf PAGESIZE"). > On 31.01.2020 19:59, Jesper Louis Andersen wrote: > > When you say /proc/pid, what are you looking at specifically in there? It > is a bit different depending on which Unix you run on, so a simple > example will help a lot. > > In particular, my early guess is going to be virtual memory vs physical > RSS mapping. The former can be much higher than the latter. Especially in > system such as Linux, which allow overcommitting memory. > > On Fri, Jan 31, 2020 at 7:22 PM Vyacheslav Levytskyy < > v.levytskyy@REDACTED> wrote: > >> Hello, >> >> I wonder why memory used by Erlang VM as reported by the kernel via the >> /proc/pid differs from erlang:memory(total). In my current configuration >> I observe realistic response from erlang:memory(total) and much lower >> values from the /proc/pid. >> >> I'm not surprised by the difference itself, but rather by the fact that >> the /proc/pid gives unrealistically lower values -- I'm not 100% sure, >> but it looks like RabbitMQ is using the /proc/pid approach by default, >> proposing also recon_alloc:memory(allocated) and erlang:memory(total) as >> available options of Erlang VM memory consumption calculation strategy. >> >> Does anybody have insights of what and why is going on with those >> calculations of memory used by Erlang VM? Is it possible to select one >> strategy beforehand for my Erlang app, or I must measure on each new >> configuration what looks more precise? Should I compare and change the >> strategy during run-time, or after I selected a strategy once for my >> configuration I can be sure that selected approach always better than >> other two? >> >> Thank you, >> Vyacheslav >> > > > -- > J. > > -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Fri Jan 31 23:33:18 2020 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Fri, 31 Jan 2020 23:33:18 +0100 Subject: memory used by Erlang VM In-Reply-To: References: <6737be5b-fef2-7f1c-7833-7300ac79d14f@yahoo.com> Message-ID: <24960b5c-c078-7434-36df-6aaf075c0c0a@ninenines.eu> On 31/01/2020 21:27, Jesper Louis Andersen wrote: > It is expected your RSS value is lower than what Erlang reports. And it would be fantastic if that was always true. But RSS is not that simple. See Gerhard's link https://grafana.gcp.rabbitmq.com/dashboard/snapshot/wM5JcgR9oQToU4CR54IbOq1NtAsa6jvu that has RSS lower than allocators report. Depending on the allocator strategies we've seen both RSS and Virt go all over the place. I'm afraid after spending months on this I still don't understand RSS. Cheers, -- Lo?c Hoguin https://ninenines.eu