<div dir="ltr">I have some experience with Qt Creator, building the GUI first and make the connection between the buttons and back-end, with separate steps like web applications.<br><br>I strongly recommend.<br><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 27, 2017 at 7:00 AM,  <span dir="ltr"><<a href="mailto:erlang-questions-request@erlang.org" target="_blank">erlang-questions-request@erlang.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Send erlang-questions mailing list submissions to<br>
        <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>
or, via email, send a message with subject or body 'help' to<br>
        <a href="mailto:erlang-questions-request@erlang.org">erlang-questions-request@<wbr>erlang.org</a><br>
<br>
You can reach the person managing the list at<br>
        <a href="mailto:erlang-questions-owner@erlang.org">erlang-questions-owner@erlang.<wbr>org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of erlang-questions digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
   1. Re:  My quest for a decent way to make a GUI in   erlang<br>
      (Albin Stig?)<br>
   2. Re:  My quest for a decent way to make a GUI in erlang (Unix One)<br>
   3. Re:  My quest for a decent way to make a GUI in erlang<br>
      (Richard A. O'Keefe)<br>
   4. Re:  os:cmd hang on OTP 18 (D?niel Szoboszlay)<br>
   5.  Patch Package OTP 20.0.2 Released (John H?gberg)<br>
<br>
<br>
------------------------------<wbr>------------------------------<wbr>----------<br>
<br>
Message: 1<br>
Date: Thu, 27 Jul 2017 02:45:57 +0200<br>
From: Albin Stig? <<a href="mailto:albin.stigo@gmail.com">albin.stigo@gmail.com</a>><br>
To: Joe Armstrong <<a href="mailto:erlang@gmail.com">erlang@gmail.com</a>><br>
Cc: Erlang <<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a>><br>
Subject: Re: [erlang-questions] My quest for a decent way to make a<br>
        GUI in  erlang<br>
Message-ID:<br>
        <<a href="mailto:CAMc%2B%2B1UG2KNvwpREQtRUhLyq1CHZrWsEmPyTbK1hhBSGi61atA@mail.gmail.com">CAMc++<wbr>1UG2KNvwpREQtRUhLyq1CHZrWsEmPy<wbr>TbK1hhBSGi61atA@mail.gmail.com</a><wbr>><br>
Content-Type: text/plain; charset="UTF-8"<br>
<br>
I think NeXT and OpenStep used display postscript? Cocoa evolved from<br>
NeXT but they moved away from display postscript for performance<br>
reasons. A lot has happened since then so maybe the time has come for<br>
display postscript?<br>
<br>
> ...a minimal system with only<br>
> the good parts (which in my mind is *just* a drawing surface, can a canvas<br>
> or SVG responsive widget) a small scripting language (say Lua or JS) and<br>
> a communication method (say JSON) and transport mechanism (say TCP)<br>
<br>
Sounds a bit like X11. But X11 isn't exactly minimal of course.<br>
Interestingly there's a shift away from this model with Mir and<br>
Wayland. From my understanding this is to make better use of modern<br>
graphics hardware; shaders etc.<br>
<br>
A canvas model is really great for graphics experiments. If someone<br>
could port something like Processing.org to Erlang, that would be<br>
really neat. But for applications I do like a native look and feel.<br>
<br>
<br>
--Albin<br>
<br>
On Wed, Jul 26, 2017 at 10:57 PM, Joe Armstrong <<a href="mailto:erlang@gmail.com">erlang@gmail.com</a>> wrote:<br>
> One other point that I omitted to make<br>
><br>
> When I wrote ex11 (a graphics experiment) I realised that<br>
> 3D objects with behaviour are *really* just 2-D objects + time.<br>
><br>
> A button is just a rectangle with a shadow draw round it. When you<br>
> click it it moves down and the shadow changes, a little while later it returns<br>
> to its original position.<br>
><br>
> I wanted to make a tabbed widget - now you might think that I could<br>
> combine buttons in some kind of hbox - well yes you can but it looks<br>
> terrible. No a tabbed widget viewed as a 2D drawing is "just" a line<br>
> that moves up and down and a few shadows in the appropriate places.<br>
><br>
> So the way to make a tabbed widget is *not* to compose a hbox of buttons<br>
> but to draw the outline of what you want in 2D and make some regions that<br>
> are sensitive to mouse clicks.<br>
><br>
> The abstractions you think you need (buttons, sliders) are not the ones that<br>
> are useful from a compositional point of view.<br>
><br>
> This is actually why I like SVG - there are two abstractions path and group<br>
> - path draws a curve. Group glues objects and has an optional affine<br>
> transformation. All other SVG objects (rectangles, circles, lines,<br>
> ...) can<br>
> be constructed from paths and groups.<br>
><br>
> Postscript is another *great* and not very well understood language -<br>
> display postscript would be great for GUIs but which is sadly not used.<br>
><br>
> It's crazy - in the browser it's really easy to mock up an interface<br>
> with SVG or a canvas or by adding things to the DOM - but on the<br>
> desktop it's a pain in the whatnot.<br>
><br>
> The answer is *not* to bundle the entire browser into a stand alone app<br>
> but to strip out the good parts  and make a minimal system with only<br>
> the good parts (which in my mind is *just* a drawing surface, can a canvas<br>
> or SVG responsive widget) a small scripting language (say Lua or JS) and<br>
> a communication method (say JSON) and transport mechanism (say TCP)<br>
><br>
> This (of course) is what we do not do :-) - instead everything that has ever<br>
> seen the light of day is bundled into the browser and the parts cannot be<br>
> easily separated.<br>
><br>
> Cheers<br>
><br>
> /Joe<br>
><br>
><br>
> On Wed, Jul 26, 2017 at 10:20 PM, Albin Stig? <<a href="mailto:albin.stigo@gmail.com">albin.stigo@gmail.com</a>> wrote:<br>
>> Hi Joe,<br>
>><br>
>> Nice research! Interesting list of software.<br>
>><br>
>> I've used a lot of GUI libraries. My favorite is Cocoa/Xcode and QT is<br>
>> pretty good too.<br>
>><br>
>> I like interface builders because you get instant visual feedback.<br>
>> Also IMHO the tricky part is not the initial layout of widgets but how<br>
>> to handle resizing. Interface builder in Xcode solves this with<br>
>> constraints. They have a learning curve but it works pretty well. For<br>
>> serious work you also have to consider i18n.<br>
>><br>
>> Cocoa is good because you can build interfaces both programmatically<br>
>> and with interface builder, and you can combine the two approaches.<br>
>> Interface builder just serializes the object graph so they are<br>
>> essentially the same.<br>
>><br>
>> I'd also say that a binding mechanism is essential to avoiding a lot<br>
>> of boilerplate code to keep the GUI updated. Cocoa has bindings (on<br>
>> osx) that's based on key value observing on (ios and osx). QT has<br>
>> signals and slots.<br>
>><br>
>><br>
>> --Albin<br>
>><br>
>><br>
>> On Wed, Jul 26, 2017 at 7:45 PM, Joe Armstrong <<a href="mailto:erlang@gmail.com">erlang@gmail.com</a>> wrote:<br>
>>> More on my search for a good (understandable) GUI engine...<br>
>>><br>
>>> I've spent the last few weeks botanising through various<br>
>>> GUI/graphics construction kits - and goodness what a mess.<br>
>>><br>
>>> I thought I'd share some of my experiences and see if<br>
>>> it resonates with anybody.<br>
>>><br>
>>> 1) Gui building is an (almost) total mess - I say almost because<br>
>>>    there is some good software around - but the good stuff tends to be<br>
>>>    experimental, undocumented and difficult to use.<br>
>>><br>
>>> 2) The most popular frameworks are bloated, difficult to use and<br>
>>>    impossible to understand without significant effort.<br>
>>><br>
>>> 3) wxWidgets and the Erlang port wxErlang is usable - but the<br>
>>>    documentation assumes you are familiar with the wxWidgets way<br>
>>>    of doing things and with OO callback programming - which is<br>
>>>    *very* Un-Erlang way of thinking<br>
>>><br>
>>> 4) The use of interface builders (Xcode, etc.) is a symptom of<br>
>>>    problem. GUI codes gets so messy that it is virtually impossible<br>
>>>    to write "by hand" - so enter the GUI builder - this is basically<br>
>>>    giving up on the idea that GUIs can be written in a clear and<br>
>>>    simple manner by hand.<br>
>>><br>
>>> 5) In the late 1970 - mid 80's there were several GUI languages<br>
>>>    and systems that were easy to use and easy to program. For<br>
>>>    example Smalltalk, TCL, Visual basic, Borland Turbo Graphics<br>
>>><br>
>>> Is there any good stuff around today?<br>
>>><br>
>>> Surprisingly the answer is yes - but the code is difficult to find<br>
>>> not supported and not mainstream.<br>
>>><br>
>>> First a couple of papers that you might find interesting:<br>
>>><br>
>>>    + <a href="http://www.eugenkiss.com/projects/thesis.pdf" rel="noreferrer" target="_blank">http://www.eugenkiss.com/<wbr>projects/thesis.pdf</a><br>
>>>      and <a href="https://github.com/eugenkiss/7guis/wiki" rel="noreferrer" target="_blank">https://github.com/eugenkiss/<wbr>7guis/wiki</a><br>
>>><br>
>>>     The author solves 7 different problems with a number of different<br>
>>>     GUI's<br>
>>><br>
>>>    + <a href="http://blog.johnnovak.net/2016/05/29/cross-platform-gui-trainwreck-2016-edition/" rel="noreferrer" target="_blank">http://blog.johnnovak.net/<wbr>2016/05/29/cross-platform-gui-<wbr>trainwreck-2016-edition/</a><br>
>>><br>
>>>    A great read - This blog has a lot of good information about the techniques<br>
>>>    used to build several state of the art GUIs (for example Reaper,<br>
>>> Blender, Light table)<br>
>>>    so If you've every wondered how fancy GUIs work this article gives<br>
>>> several clues.<br>
>>><br>
>>>    It also has the rather nice example of a GUI written using the<br>
>>> Electron Framework<br>
>>>    that made an 189 MB executable to bang up a window with a small number of<br>
>>>    controls in it.<br>
>>><br>
>>>    There's a list of references in one of the comments to this blog that<br>
>>>    lead to several interesting *small'ish GUIs'<br>
>>><br>
>>> Good stuff<br>
>>><br>
>>>    I did find some good software and some potentially very good software.<br>
>>>    My top picks are as follows:<br>
>>><br>
>>>    <a href="http://inscore.sourceforge.net/" rel="noreferrer" target="_blank">http://inscore.sourceforge.<wbr>net/</a><br>
>>><br>
>>>       This is my favorite from an architectural POV.<br>
>>>       It is controlled entirely by sending it messages.<br>
>>>       Not a single callback to be seen<br>
>>><br>
>>>    <a href="https://github.com/andlabs/libui" rel="noreferrer" target="_blank">https://github.com/andlabs/<wbr>libui</a><br>
>>><br>
>>>       This looks very promising - it's a cross platform adaption layer<br>
>>>       with a C interface - I've only build it on a Mac but<br>
>>>       the adaption layer looks pretty easy to use. There's a C interface<br>
>>>       that could be adapted to Erlang.<br>
>>><br>
>>>       There are very few examples<br>
>>> <a href="https://github.com/andlabs/ui/wiki/Getting-Started" rel="noreferrer" target="_blank">https://github.com/andlabs/ui/<wbr>wiki/Getting-Started</a><br>
>>>       has a go example - but if you download and build the system the<br>
>>>       C examples are easy to follow.<br>
>>><br>
>>>    <a href="http://www.red-lang.org/" rel="noreferrer" target="_blank">http://www.red-lang.org/</a><br>
>>><br>
>>>       Is amazing - Red is a language inspired by REBOL.<br>
>>><br>
>>>       REBOL never achieved much popularity - perhaps Red will.<br>
>>>       Once you've see red you'll wonder why you program in anything else<br>
>>>       (there are good reasons - but for simply desktop apps Red is great).<br>
>>><br>
>>>    <a href="https://github.com/wjakob/nanogui" rel="noreferrer" target="_blank">https://github.com/wjakob/<wbr>nanogui</a><br>
>>><br>
>>>       Restores my faith in programming - it's small and built on top<br>
>>>       of <a href="https://github.com/memononen/NanoVG" rel="noreferrer" target="_blank">https://github.com/memononen/<wbr>NanoVG</a><br>
>>><br>
>>>       NanoVG is basically a canvas type interface to OpenGL<br>
>>><br>
>>>       Reading the NanoGui code made me wonder if the best way to make<br>
>>>       a GUI for erlang would be to use OpenGL for the low-level stuff<br>
>>>       and do all the rest in Erlang.<br>
>>><br>
>>>       Buttons etc. are pretty easy to define as processes which I believe<br>
>>>       is the way <a href="http://www.wings3d.com/" rel="noreferrer" target="_blank">http://www.wings3d.com/</a> did things.<br>
>>><br>
>>> The future<br>
>>><br>
>>> I'm still undecided - one of more of the following seem attractive<br>
>>><br>
>>>     1) wxErlang - it works *but* it's big and ugly and has a nasty<br>
>>>        programming model<br>
>>>     2) An interface to Red would be great - but red is pretty unknown<br>
>>>     3) libui looks promising - anybody interested in this?<br>
>>>     4) the nanogui/NanoVG track looks good - anything with nano in the<br>
>>>        name has my vote<br>
>>>     5) The inscore architecture rules - NO CALLBACKS - Yea<br>
>>><br>
>>> Verily verily I say unto you - "useth not the callback, even though<br>
>>> they that useth the callback are ignited with a great passion and<br>
>>> extol the virtues of the callback - for therein lies the madness<br>
>>> that do come when the callback faileth for reasons not comprehended'<br>
>>><br>
>>> Thus it is writ.<br>
>>><br>
>>> Cheers<br>
>>><br>
>>> /Joe<br>
>>> ______________________________<wbr>_________________<br>
>>> erlang-questions mailing list<br>
>>> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
>>> <a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Thu, 27 Jul 2017 02:03:07 +0000<br>
From: Unix One <<a href="mailto:unix1@live.com">unix1@live.com</a>><br>
To: Albin Stig? <<a href="mailto:albin.stigo@gmail.com">albin.stigo@gmail.com</a>>, Joe Armstrong<br>
        <<a href="mailto:erlang@gmail.com">erlang@gmail.com</a>><br>
Cc: Erlang <<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a>><br>
Subject: Re: [erlang-questions] My quest for a decent way to make a<br>
        GUI in erlang<br>
Message-ID:<br>
        <<a href="mailto:BY2PR19MB03755D9CB02781C63B6F64E598BE0@BY2PR19MB0375.namprd19.prod.outlook.com">BY2PR19MB03755D9CB02781C63B6F<wbr>64E598BE0@BY2PR19MB0375.<wbr>namprd19.prod.outlook.com</a>><br>
<br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
On 07/26/2017 01:20 PM, Albin Stig? wrote:<br>
<br>
> QT has signals and slots.<br>
><br>
<br>
I haven't done big projects in Qt, but little fiddling I did with a<br>
small GUI app, I found Qt+QML a pleasure to work with.<br>
<br>
Searching for Erlang-related examples, it just took about 30 secs to try<br>
this on my laptop:<br>
<br>
<a href="https://github.com/krant/eqml" rel="noreferrer" target="_blank">https://github.com/krant/eqml</a><br>
<br>
It's showing passing Erlang messages as signals to Qt slots and vice<br>
versa. If I were doing GUIs with Erlang, this would be one place I'd<br>
look closer.<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Thu, 27 Jul 2017 14:53:17 +1200<br>
From: "Richard A. O'Keefe" <<a href="mailto:ok@cs.otago.ac.nz">ok@cs.otago.ac.nz</a>><br>
To: <<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a>><br>
Subject: Re: [erlang-questions] My quest for a decent way to make a<br>
        GUI in erlang<br>
Message-ID: <<a href="mailto:9dbb9326-c196-28f3-3340-fe757ab8d0ef@cs.otago.ac.nz">9dbb9326-c196-28f3-3340-<wbr>fe757ab8d0ef@cs.otago.ac.nz</a>><br>
Content-Type: text/plain; charset="utf-8"; format=flowed<br>
<br>
<br>
<br>
On 27/07/17 12:45 PM, Albin Stig? wrote:<br>
> I think NeXT and OpenStep used display postscript? Cocoa evolved from<br>
> NeXT but they moved away from display postscript for performance<br>
> reasons. A lot has happened since then so maybe the time has come for<br>
> display postscript?<br>
<br>
Before Display Postscript (developed for Apple)<br>
there was NeWS.  See the NeWS book at<br>
<a href="http://bitsavers.trailing-edge.com/pdf/sun/NeWS/The_NeWS_Book_1989.pdf" rel="noreferrer" target="_blank">http://bitsavers.trailing-<wbr>edge.com/pdf/sun/NeWS/The_<wbr>NeWS_Book_1989.pdf</a><br>
<br>
Programming in a concurrent OO extension of Postscript never really<br>
appealed to me, and the performance issues of thread decades ago<br>
probably look quite different today with GPUs.<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Thu, 27 Jul 2017 07:21:20 +0000<br>
From: D?niel Szoboszlay <<a href="mailto:dszoboszlay@gmail.com">dszoboszlay@gmail.com</a>><br>
To: Dmytro Lytovchenko <<a href="mailto:dmytro.lytovchenko@gmail.com">dmytro.lytovchenko@gmail.com</a>><br>
Cc: erlang-questions <<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a>><br>
Subject: Re: [erlang-questions] os:cmd hang on OTP 18<br>
Message-ID:<br>
        <<a href="mailto:CADcfxonPG7CEX4ieX5YWsYicPC_143bs-78YeiBF0nDoTadi8g@mail.gmail.com">CADcfxonPG7CEX4ieX5YWsYicPC_<wbr>143bs-78YeiBF0nDoTadi8g@mail.<wbr>gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Thanks Dmytro, this really helped a lot!<br>
<br>
I think the commit you pointed to is not directly related: it only changes<br>
Erlang code, and if the behaviour depends on whether you are using a<br>
release/debug build, the root cause is most probably somewhere in the C<br>
code of erts.<br>
<br>
But the commit message talks about the emulator no longer using vfork, and<br>
it was a good clue: disabling vfork on 18 prevents the problem. So this one<br>
will finish:<br>
<br>
ERL_NO_VFORK=true erl +A0 +S 1:1 -noinput -noshell -eval 'os:cmd("tar -C<br>
/tmp/ -xf /tmp/tartest --use-compress-program=lbzip2"<wbr>), init:stop().'<br>
<br>
Thanks again for the clue, I will look into the difference between using<br>
fork/vfork in OTP 18!<br>
<br>
Daniel<br>
<br>
On Thu, 27 Jul 2017 at 02:09 Dmytro Lytovchenko <<br>
<a href="mailto:dmytro.lytovchenko@gmail.com">dmytro.lytovchenko@gmail.com</a>> wrote:<br>
<br>
> I could observe the behaviour only in R18, but not in R19 and not in R20<br>
> I also could not reproduce it in debug flavour of R18 emulator, but it<br>
> reproduces reliably in release SMP variant.<br>
><br>
> The changes to os.erl between 18.3.4.5 and 19.0 include removal of os:cmd<br>
> server which might somehow be related (commit<br>
> *<wbr>200247f972b012ced0c4b2c6611f09<wbr>1af66ebedd*). This commit *possibly* fixes<br>
> the behavior ? in R19 (build 19.0 by Kerl) the behaviour does not happen.<br>
><br>
> 2017-07-26 21:47 GMT+02:00 D?niel Szoboszlay <<a href="mailto:dszoboszlay@gmail.com">dszoboszlay@gmail.com</a>>:<br>
><br>
>> Honestly, I didn't try with other command variations. There are many<br>
>> commands that do not hang when run from os:cmd, regardless of the OTP<br>
>> version. But this particular command does hang with one OTP version, and<br>
>> not with the other OTP version. So the difference is in OTP, and I want to<br>
>> find out what has changed.<br>
>><br>
>> Daniel<br>
>><br>
>> On Wed, 26 Jul 2017 at 21:34 Dmytro Lytovchenko <<br>
>> <a href="mailto:dmytro.lytovchenko@gmail.com">dmytro.lytovchenko@gmail.com</a>> wrote:<br>
>><br>
>>> Is it something lbzip2 related?<br>
>>> Did you try normal single-thread bzip2? (-j flag or --bzip2)<br>
>>> What is you use gzip? (-z or --gzip)<br>
>>><br>
>>> 2017-07-26 21:27 GMT+02:00 D?niel Szoboszlay <<a href="mailto:dszoboszlay@gmail.com">dszoboszlay@gmail.com</a>>:<br>
>>><br>
>>>> Hi,<br>
>>>><br>
>>>> I've encountered a strange problem with os:cmd when running tar and<br>
>>>> lbzip2. Steps to reproduce:<br>
>>>><br>
>>>> # create some lbzip2 compressed data<br>
>>>><br>
>>>> dd if=/dev/urandom of=/tmp/testfile count=10<br>
>>>> tar -cf - -C /tmp testfile | lbzip2 -6 -n 4 | dd of=/tmp/tartest status=none<br>
>>>><br>
>>>><br>
>>>> # try to extract the archive from Erlang with os:cmd<br>
>>>><br>
>>>> erl -noinput -eval 'os:cmd("tar -C /tmp/ -xf /tmp/tartest --use-compress-program=lbzip2"<wbr>), init:stop().'<br>
>>>><br>
>>>><br>
>>>> This worked fine with OTP 17.5.6.7, but with OTP 18.3.4.5 the command<br>
>>>> hangs: lbzip2 just sits in a rt_sigsuspend syscall waiting for a USR2, PIPE<br>
>>>> or XFSZ signal. And its parent, the tar process waits in a wait4 syscall<br>
>>>> for lbzip2 to terminate.<br>
>>>><br>
>>>> I don't have at the moment any newer OTP version installed, I'm not<br>
>>>> sure how OTP 19 or 20 would behave.<br>
>>>><br>
>>>> I tried to strace the processes, but there's too much noise, I couldn't<br>
>>>> yet figure out anything interesting there.<br>
>>>><br>
>>>> I also tried to diff OTP 17 & 18, but os:cmd/1 and friends didn't<br>
>>>> change. I'm not sure about the port code, but at least the release notes<br>
>>>> didn't mention anything major. Or did I miss something? Does anyone have an<br>
>>>> idea what may have changed between these OTP versions?<br>
>>>><br>
>>>> Thanks,<br>
>>>> Daniel<br>
>>>><br>
>>>> ______________________________<wbr>_________________<br>
>>>> erlang-questions mailing list<br>
>>>> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
>>>> <a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>
>>>><br>
>>>><br>
>>><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://erlang.org/pipermail/erlang-questions/attachments/20170727/2c790fa8/attachment-0001.html" rel="noreferrer" target="_blank">http://erlang.org/pipermail/<wbr>erlang-questions/attachments/<wbr>20170727/2c790fa8/attachment-<wbr>0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Thu, 27 Jul 2017 07:30:05 +0000<br>
From: John H?gberg <<a href="mailto:john.hogberg@ericsson.com">john.hogberg@ericsson.com</a>><br>
To: "<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a>" <<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a>><br>
Subject: [erlang-questions] Patch Package OTP 20.0.2 Released<br>
Message-ID:<br>
        <<a href="mailto:AM4PR07MB149062967A47EAB472EADEBEF6BE0@AM4PR07MB1490.eurprd07.prod.outlook.com">AM4PR07MB149062967A47EAB472EA<wbr>DEBEF6BE0@AM4PR07MB1490.<wbr>eurprd07.prod.outlook.com</a>><br>
<br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Patch Package:           OTP 20.0.2<br>
Git Tag:                 OTP-20.0.2<br>
Date:                    2017-07-27<br>
Trouble Report Id:       OTP-14494, OTP-14498, OTP-14509, OTP-14514,<br>
                         OTP-14519<br>
Seq num:                 ERIERL-49<br>
System:                  OTP<br>
Release:                 20<br>
Application:             asn1-5.0.1, erts-9.0.2, kernel-5.3.1<br>
Predecessor:             OTP 20.0.1<br>
<br>
 Check out the git tag OTP-20.0.2, and build a full OTP system<br>
 including documentation. Apply one or more applications from this<br>
 build as patches to your installation using the 'otp_patch_apply'<br>
 tool. For information on install requirements, see descriptions for<br>
 each application version below.<br>
<br>
 ------------------------------<wbr>------------------------------<wbr>---------<br>
 --- asn1-5.0.1 ------------------------------<wbr>------------------------<br>
 ------------------------------<wbr>------------------------------<wbr>---------<br>
<br>
 The asn1-5.0.1 application can be applied independently of other<br>
 applications on a full OTP 20 installation.<br>
<br>
 --- Fixed Bugs and Malfunctions ---<br>
<br>
  OTP-14519    Application(s): asn1<br>
               Related Id(s): ERIERL-49<br>
<br>
               Fixed compilation error of generated code caused by a<br>
               missing quotation of function names as part of an<br>
               external call for encoding.<br>
<br>
<br>
 Full runtime dependencies of asn1-5.0.1: erts-7.0, kernel-3.0,<br>
 stdlib-2.0<br>
<br>
<br>
 ------------------------------<wbr>------------------------------<wbr>---------<br>
 --- erts-9.0.2 ------------------------------<wbr>------------------------<br>
 ------------------------------<wbr>------------------------------<wbr>---------<br>
<br>
 The erts-9.0.2 application can be applied independently of other<br>
 applications on a full OTP 20 installation.<br>
<br>
 --- Fixed Bugs and Malfunctions ---<br>
<br>
  OTP-14494    Application(s): erts<br>
<br>
               Added missing release notes for OTP-14491 ("performance<br>
               bug in pre-allocators") which was included in<br>
               erts-9.0.1 (OTP-20.0.1).<br>
<br>
<br>
  OTP-14509    Application(s): erts<br>
<br>
               Fixed a bug that prevented TCP sockets from being<br>
               closed properly on send timeouts.<br>
<br>
<br>
  OTP-14514    Application(s): erts<br>
<br>
               Fixed bug in operator bxor causing erroneuos result<br>
               when one operand is a big *negative* integer with the<br>
               lowest N*W bits as zero and the other operand not<br>
               larger than N*W bits. N is an integer of 1 or larger<br>
               and W is 32 or 64 depending on word size.<br>
<br>
<br>
 Full runtime dependencies of erts-9.0.2: kernel-5.0, sasl-3.0.1,<br>
 stdlib-3.0<br>
<br>
<br>
 ------------------------------<wbr>------------------------------<wbr>---------<br>
 --- kernel-5.3.1 ------------------------------<wbr>----------------------<br>
 ------------------------------<wbr>------------------------------<wbr>---------<br>
<br>
 The kernel-5.3.1 application can be applied independently of other<br>
 applications on a full OTP 20 installation.<br>
<br>
 --- Fixed Bugs and Malfunctions ---<br>
<br>
  OTP-14498    Application(s): kernel<br>
<br>
               The documentation for the 'quiet' option in<br>
               disk_log:open/1 had an incorrect default value.<br>
<br>
<br>
 Full runtime dependencies of kernel-5.3.1: erts-9.0, sasl-3.0,<br>
 stdlib-3.0<br>
<br>
<br>
 ------------------------------<wbr>------------------------------<wbr>---------<br>
 ------------------------------<wbr>------------------------------<wbr>---------<br>
 ------------------------------<wbr>------------------------------<wbr>---------<br>
<br>
<br>
------------------------------<br>
<br>
______________________________<wbr>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>
<br>
<br>
End of erlang-questions Digest, Vol 332, Issue 5<br>
******************************<wbr>******************<br>
</blockquote></div><br></div></div></div></div>