Project status

[lessless]

Hello peeps,

It's a sorrow to see that such extraordinaire project isn't being updated! What is the current status and future plans?

[maximk]

All recent updates to the code were customer-driven. New users mean new updates. The likely application area for this is NFV, modular software for telecoms. No definite plans,

[amirmc]

@maximk You might find the following post interesting, given that you mention NFV. You probably met Wassim and Heikki at SCaLE.
http://unikernel.org/blog/2016/unikernel-nfv-platform

[bmalum]

it's sad to see such a peace rotting here … so i would offer my open source time to work here but i'm kinda new to unikernels … but if someone will give me a hand here to start and how - i would love to keep this running.

[EarlGray]

@bmalum I'm glad to help, I'm available at https://gitter.im/cloudozer/ling or in personal messaging there.

P.S. I took part in developing LING in the past.

[stephb9959]

I too would like to revive this project. I have been trying to bring this to V19 of Erlang but running into compile time issues when running 'railing image'. Any pointers or doc or anything to point me in the right direction would be amazing...

[idcrisis]

Please. Zero OS unikernels is very important. Not the least being practically zero attack surface.

[stephb9959]

@EarlGray Let me ask you, if you were tasked to bring LING to V19, where would you start? I tried the simple, get it to compile under the latest revs, fixed all the warnings, added Erlang:time stamp as a BIF... all seemed ok but running Railing generates an exception in one of the encoding beam encoding libraries... Where could you point me?

Thanks for any help...

[maximk]

You can send the error logs to me. If it is something that only takes an hour I will help you out. --Maxim

…

On Sat, Mar 18, 2017 at 8:01 PM, Stephane Bourque ***@***.***> wrote: @EarlGray <https://github.com/EarlGray> Let me ask you, if you were tasked to bring LING to V19, where would you start? I tried the simple, get it to compile under the latest revs, fixed all the warnings, added Erlang:time stamp as a BIF... all seemed ok but running Railing generates an exception in one of the encoding beam encoding libraries... Where could you point me? Thanks for any help... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#141 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEFTAvo4SvJMXb_-uM3uMTcW3u04h11ks5rnBvtgaJpZM4ImGyY> .

[stephb9959]

@maximk Thanks for helping...

Here is the first significant warning

core/ling_main.c: In function ‘proc_main’:
core/ling_main.c:5678:3: warning: array subscript is above array bounds [-Warray-bounds]
rs[1022] = *(term_t *)expand_ptr(tmp_arg1);
^
core/ling_main.c:5976:7: warning: array subscript is above array bounds [-Warray-bounds]
if (rs[1022] != (term_t)ip[2])
^

Now changing NUM_REGS to 1024 fixes the warning, but I see some significance to 1022.

Here is the error when running railing image for cowboy's hello_world example.

_Compile: rel/hello_world_example/lib/asn1-4.0.4/ebin/asn1ct_check.beam
escript: exception error: no function clause matching ling_lib:enc({reg_as_term,1022}) (bc/ling_lib.erl, line 233)
in function ling_lib:'-encode/1-lc$^0/1-0-'/1 (bc/ling_lib.erl, line 231)
in call from ling_lib:'-encode/1-lc$^0/1-0-'/1 (bc/ling_lib.erl, line 231)
in call from ling_lib:encode/1 (bc/ling_lib.erl, line 231)
in call from ling_lib:code_chunk/1 (bc/ling_lib.erl, line 174)
in call from ling_lib:specs_to_binary/1 (bc/ling_lib.erl, line 125)
in call from railing:compile/2 (railing/railing.erl, line 399)
in call from railing:'-main/1-lc$^9/1-8-'/2 (railing/railing.erl, line 198)

This 1022 pops again. Happens wetter the NUM_REGS is set to 1024 too.

I compiled LING with the latest build-essential, using Erlang V19.2

I added a new BIF for erlang:timestamp() (I just duplicated what was there for erlang:now() ).

Let me know if you need anything else.

Thanks

[maximk]

This is likely a change to the Erlang compiler introduced in R19. The compiler used to emit references to a 'temporary' registers, such as r1024 despite the fact that there are only 256 registers. Maybe, now compiler emit references to more of such short-lived out-of-bound registers. Anyways, the investigation and correction will take considerable time I do not have now. Regards, M

…

On Mon, Mar 20, 2017 at 6:16 AM, Stephane Bourque ***@***.***> wrote: @maximk <https://github.com/maximk> Thanks for helping... Here is the first significant warning *core/ling_main.c: In function ‘proc_main’: core/ling_main.c:5678:3: warning: array subscript is above array bounds [-Warray-bounds] rs[1022] = *(term_t *)expand_ptr(tmp_arg1); ^ core/ling_main.c:5976:7: warning: array subscript is above array bounds [-Warray-bounds] if (rs[1022] != (term_t)ip[2]) ^* Now changing NUM_REGS to 1024 fixes the warning, but I see some significance to 1022. Here is the error when running railing image for cowboy's hello_world example. _Compile: *rel/hello_world_example/lib/asn1-4.0.4/ebin/asn1ct_check.beam escript: exception error: no function clause matching ling_lib:enc({reg_as_term,1022}) (bc/ling_lib.erl, line 233) in function ling_lib:'-encode/1-lc$^0/1-0-'/1 (bc/ling_lib.erl, line 231) in call from ling_lib:'-encode/1-lc$^0/1-0-'/1 (bc/ling_lib.erl, line 231) in call from ling_lib:encode/1 (bc/ling_lib.erl, line 231) in call from ling_lib:code_chunk/1 (bc/ling_lib.erl, line 174) in call from ling_lib:specs_to_binary/1 (bc/ling_lib.erl, line 125) in call from railing:compile/2 (railing/railing.erl, line 399) in call from railing:'-main/1-lc$^9/1-8-'/2 (railing/railing.erl, line 198)* This 1022 pops again. Happens wetter the NUM_REGS is set to 1024 too. I compiled LING with the latest build-essential, using Erlang V19.2 I added a new BIF for erlang:timestamp() (I just duplicated what was there for erlang:now() ). Let me know if you need anything else. Thanks — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#141 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEFTA0aJNG1PAhQG2ncGe_WjwrW9U7pks5rnf2HgaJpZM4ImGyY> .

[stephb9959]

Thanks for looking into this Maxim. I am still interested. If you could point me in the right direction, I would love to investigate and see if I can address this issue. I assume I need to look for changes in Beam in R19 to previous revs. Are there some additional docs for Ling and how it differs from Beam? I appreciate any info.. On Tue, Mar 21, 2017 at 19:08 Maksym Kharchenko <notifications@github.com> wrote:

…

This is likely a change to the Erlang compiler introduced in R19. The compiler used to emit references to a 'temporary' registers, such as r1024 despite the fact that there are only 256 registers. Maybe, now compiler emit references to more of such short-lived out-of-bound registers. Anyways, the investigation and correction will take considerable time I do not have now. Regards, M On Mon, Mar 20, 2017 at 6:16 AM, Stephane Bourque < ***@***.***> wrote: > @maximk <https://github.com/maximk> Thanks for helping... > > Here is the first significant warning > > > > > > > > *core/ling_main.c: In function ‘proc_main’: core/ling_main.c:5678:3: > warning: array subscript is above array bounds [-Warray-bounds] rs[1022] = > *(term_t *)expand_ptr(tmp_arg1); ^ core/ling_main.c:5976:7: warning: array > subscript is above array bounds [-Warray-bounds] if (rs[1022] != > (term_t)ip[2]) ^* > > Now changing NUM_REGS to 1024 fixes the warning, but I see some > significance to 1022. > > Here is the error when running railing image for cowboy's hello_world > example. > > _Compile: > > > > > > > > *rel/hello_world_example/lib/asn1-4.0.4/ebin/asn1ct_check.beam escript: > exception error: no function clause matching > ling_lib:enc({reg_as_term,1022}) (bc/ling_lib.erl, line 233) in function > ling_lib:'-encode/1-lc$^0/1-0-'/1 (bc/ling_lib.erl, line 231) in call from > ling_lib:'-encode/1-lc$^0/1-0-'/1 (bc/ling_lib.erl, line 231) in call from > ling_lib:encode/1 (bc/ling_lib.erl, line 231) in call from > ling_lib:code_chunk/1 (bc/ling_lib.erl, line 174) in call from > ling_lib:specs_to_binary/1 (bc/ling_lib.erl, line 125) in call from > railing:compile/2 (railing/railing.erl, line 399) in call from > railing:'-main/1-lc$^9/1-8-'/2 (railing/railing.erl, line 198)* > > This 1022 pops again. Happens wetter the NUM_REGS is set to 1024 too. > > I compiled LING with the latest build-essential, using Erlang V19.2 > > I added a new BIF for erlang:timestamp() (I just duplicated what was there > for erlang:now() ). > > Let me know if you need anything else. > > Thanks > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#141 (comment)>, or mute > the thread > < https://github.com/notifications/unsubscribe-auth/AAEFTA0aJNG1PAhQG2ncGe_WjwrW9U7pks5rnf2HgaJpZM4ImGyY > > . > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#141 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABxfxBljYA4K70vAJorykcvY14vgcm58ks5rn6-fgaJpZM4ImGyY> .

[maximk]

Stephane, I have found a possible fix for you. See bc/ling_code.erl lines 90-91. It converts reg 1023 (non-existent) to reg 255 (rarely used). It is a hack in the same vein as reg 1023 is a hack. You can add another case to convert reg 1022 to reg 254. A few comments on how LING and BEAM differ: 1. Both LING and BEAM use the same high-level instruction set you can see when you disassemble BEAM files. However, it is not the instruction set VMs execute. They execute highly-optimized low-level instructions and these are different between LING and BEAM. The low-level instruction set for LING is bc/iops.tab. 2. BEAM translates from high-level to low-level instructions upon module load. For this it uses a sophisticated engine similar to a Prolog interpreter. LING does the translation statically upon compilation of the module. .ling files contain low-level instructions. The goal of the approach is to make LING start faster. 3. Both BEAM and LING use specialized 'variants' for low-level instructions. For instance, there may be instruction variant to add a register to reg0 and a more general variant to add two arbitrary registers. The difference is that BEAM enumerates all instruction variants statically. LING 'discovers' optimal instruction variants by collecting statistics on a body of Erlang sources (stdlib). More variants allow the C compiler produces a faster code, but at the same time increase the code size of the interpreter. You can see discovered instruction variants in bc/ling_iopvars.erl (after the build). 4. The main source of LING interpreter is core/ling_main.c. The file is generated to accommodate for all instruction variants discovered earlier. Regards, M On Sat, Mar 25, 2017 at 2:33 AM, Stephane Bourque <notifications@github.com> wrote:

…

Thanks for looking into this Maxim. I am still interested. If you could point me in the right direction, I would love to investigate and see if I can address this issue. I assume I need to look for changes in Beam in R19 to previous revs. Are there some additional docs for Ling and how it differs from Beam? I appreciate any info.. On Tue, Mar 21, 2017 at 19:08 Maksym Kharchenko ***@***.***> wrote: > This is likely a change to the Erlang compiler introduced in R19. > > The compiler used to emit references to a 'temporary' registers, such as > r1024 despite the fact that there are only 256 registers. Maybe, now > compiler emit references to more of such short-lived out-of-bound > registers. > > Anyways, the investigation and correction will take considerable time I do > not have now. > > Regards, > M > > > On Mon, Mar 20, 2017 at 6:16 AM, Stephane Bourque < > ***@***.***> > wrote: > > > @maximk <https://github.com/maximk> Thanks for helping... > > > > Here is the first significant warning > > > > > > > > > > > > > > > > *core/ling_main.c: In function ‘proc_main’: core/ling_main.c:5678:3: > > warning: array subscript is above array bounds [-Warray-bounds] rs[1022] > = > > *(term_t *)expand_ptr(tmp_arg1); ^ core/ling_main.c:5976:7: warning: > array > > subscript is above array bounds [-Warray-bounds] if (rs[1022] != > > (term_t)ip[2]) ^* > > > > Now changing NUM_REGS to 1024 fixes the warning, but I see some > > significance to 1022. > > > > Here is the error when running railing image for cowboy's hello_world > > example. > > > > _Compile: > > > > > > > > > > > > > > > > *rel/hello_world_example/lib/asn1-4.0.4/ebin/asn1ct_check.beam escript: > > exception error: no function clause matching > > ling_lib:enc({reg_as_term,1022}) (bc/ling_lib.erl, line 233) in function > > ling_lib:'-encode/1-lc$^0/1-0-'/1 (bc/ling_lib.erl, line 231) in call > from > > ling_lib:'-encode/1-lc$^0/1-0-'/1 (bc/ling_lib.erl, line 231) in call > from > > ling_lib:encode/1 (bc/ling_lib.erl, line 231) in call from > > ling_lib:code_chunk/1 (bc/ling_lib.erl, line 174) in call from > > ling_lib:specs_to_binary/1 (bc/ling_lib.erl, line 125) in call from > > railing:compile/2 (railing/railing.erl, line 399) in call from > > railing:'-main/1-lc$^9/1-8-'/2 (railing/railing.erl, line 198)* > > > > This 1022 pops again. Happens wetter the NUM_REGS is set to 1024 too. > > > > I compiled LING with the latest build-essential, using Erlang V19.2 > > > > I added a new BIF for erlang:timestamp() (I just duplicated what was > there > > for erlang:now() ). > > > > Let me know if you need anything else. > > > > Thanks > > > > — > > You are receiving this because you were mentioned. > > Reply to this email directly, view it on GitHub > > <#141 (comment)>, > or mute > > the thread > > < > https://github.com/notifications/unsubscribe- auth/AAEFTA0aJNG1PAhQG2ncGe_WjwrW9U7pks5rnf2HgaJpZM4ImGyY > > > > . > > > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <#141 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/ ABxfxBljYA4K70vAJorykcvY14vgcm58ks5rn6-fgaJpZM4ImGyY> > . > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#141 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEFTOY5ys2v8B21MEzEQiQQk9M0ho_qks5rpGDxgaJpZM4ImGyY> .

[stephb9959]

Fantastic Maxim! Made the suggested change and all compiles. Railing works. The generated image crashes during an assert() in proc_make line 61, ... core/proc.c The image then freezes up... Do you know if there is a reason or something would be limiting running LING on 32 bit OS? Or compiled in 32 bit mode? I see a lot of casting to (u_int32) and memory compares and for sure this would fail on 64 bit OS. Am I out to lunch? Am I missing some flag when starting the image? Thanks again... On Sat, Mar 25, 2017 at 3:03 AM Maksym Kharchenko <notifications@github.com> wrote: Stephane, I have found a possible fix for you. See bc/ling_code.erl lines 90-91. It converts reg 1023 (non-existent) to reg 255 (rarely used). It is a hack in the same vein as reg 1023 is a hack. You can add another case to convert reg 1022 to reg 254. A few comments on how LING and BEAM differ: 1. Both LING and BEAM use the same high-level instruction set you can see when you disassemble BEAM files. However, it is not the instruction set VMs execute. They execute highly-optimized low-level instructions and these are different between LING and BEAM. The low-level instruction set for LING is bc/iops.tab. 2. BEAM translates from high-level to low-level instructions upon module load. For this it uses a sophisticated engine similar to a Prolog interpreter. LING does the translation statically upon compilation of the module. .ling files contain low-level instructions. The goal of the approach is to make LING start faster. 3. Both BEAM and LING use specialized 'variants' for low-level instructions. For instance, there may be instruction variant to add a register to reg0 and a more general variant to add two arbitrary registers. The difference is that BEAM enumerates all instruction variants statically. LING 'discovers' optimal instruction variants by collecting statistics on a body of Erlang sources (stdlib). More variants allow the C compiler produces a faster code, but at the same time increase the code size of the interpreter. You can see discovered instruction variants in bc/ling_iopvars.erl (after the build). 4. The main source of LING interpreter is core/ling_main.c. The file is generated to accommodate for all instruction variants discovered earlier. Regards, M On Sat, Mar 25, 2017 at 2:33 AM, Stephane Bourque <notifications@github.com> wrote:

Thanks for looking into this Maxim. I am still interested. If you could point me in the right direction, I would love to investigate and see if I can address this issue. I assume I need to look for changes in Beam in R19 to previous revs. Are there some additional docs for Ling and how it differs from Beam? I appreciate any info.. On Tue, Mar 21, 2017 at 19:08 Maksym Kharchenko ***@***.***> wrote: > This is likely a change to the Erlang compiler introduced in R19. > > The compiler used to emit references to a 'temporary' registers, such as > r1024 despite the fact that there are only 256 registers. Maybe, now > compiler emit references to more of such short-lived out-of-bound > registers. > > Anyways, the investigation and correction will take considerable time I do > not have now. > > Regards, > M > > > On Mon, Mar 20, 2017 at 6:16 AM, Stephane Bourque < > ***@***.***> > wrote: > > > @maximk <https://github.com/maximk> Thanks for helping... > > > > Here is the first significant warning > > > > > > > > > > > > > > > > *core/ling_main.c: In function ‘proc_main’: core/ling_main.c:5678:3: > > warning: array subscript is above array bounds [-Warray-bounds] rs[1022] > = > > *(term_t *)expand_ptr(tmp_arg1); ^ core/ling_main.c:5976:7: warning: > array > > subscript is above array bounds [-Warray-bounds] if (rs[1022] != > > (term_t)ip[2]) ^* > > > > Now changing NUM_REGS to 1024 fixes the warning, but I see some > > significance to 1022. > > > > Here is the error when running railing image for cowboy's hello_world > > example. > > > > _Compile: > > > > > > > > > > > > > > > > *rel/hello_world_example/lib/asn1-4.0.4/ebin/asn1ct_check.beam escript: > > exception error: no function clause matching > > ling_lib:enc({reg_as_term,1022}) (bc/ling_lib.erl, line 233) in function > > ling_lib:'-encode/1-lc$^0/1-0-'/1 (bc/ling_lib.erl, line 231) in call > from > > ling_lib:'-encode/1-lc$^0/1-0-'/1 (bc/ling_lib.erl, line 231) in call > from > > ling_lib:encode/1 (bc/ling_lib.erl, line 231) in call from > > ling_lib:code_chunk/1 (bc/ling_lib.erl, line 174) in call from > > ling_lib:specs_to_binary/1 (bc/ling_lib.erl, line 125) in call from > > railing:compile/2 (railing/railing.erl, line 399) in call from > > railing:'-main/1-lc$^9/1-8-'/2 (railing/railing.erl, line 198)* > > > > This 1022 pops again. Happens wetter the NUM_REGS is set to 1024 too. > > > > I compiled LING with the latest build-essential, using Erlang V19.2 > > > > I added a new BIF for erlang:timestamp() (I just duplicated what was > there > > for erlang:now() ). > > > > Let me know if you need anything else. > > > > Thanks > > > > — > > You are receiving this because you were mentioned. > > Reply to this email directly, view it on GitHub > > <#141 (comment)>, > or mute > > the thread > > < > https://github.com/notifications/unsubscribe- auth/AAEFTA0aJNG1PAhQG2ncGe_WjwrW9U7pks5rnf2HgaJpZM4ImGyY > > > > . > > > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <#141 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/ ABxfxBljYA4K70vAJorykcvY14vgcm58ks5rn6-fgaJpZM4ImGyY> > . > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#141 (comment)>, or

mute

the thread <

https://github.com/notifications/unsubscribe-auth/AAEFTOY5ys2v8B21MEzEQiQQk9M0ho_qks5rpGDxgaJpZM4ImGyY

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <#141 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABxfxBjZo0MxWXvzmLBy_HP5G_KHFH2Lks5rpOZVgaJpZM4ImGyY> .

[maximk]

Historically, LING started as 32-bit only. The porting to 64-bit was easy (half a day), but later I dropped the 32-bit support, mostly, because Xen dropped it too. Maybe you can dig up these changes in the commit history. In general, terms are 32-bit in LING and there must not be much needed to run it on 32-bit OS. You can grep the code for int_ptr_t or sizeof(void *). These are most likely culprits. M On Sun, Mar 26, 2017 at 2:17 AM, Stephane Bourque <notifications@github.com> wrote:

…

Fantastic Maxim! Made the suggested change and all compiles. Railing works. The generated image crashes during an assert() in proc_make line 61, ... core/proc.c The image then freezes up... Do you know if there is a reason or something would be limiting running LING on 32 bit OS? Or compiled in 32 bit mode? I see a lot of casting to (u_int32) and memory compares and for sure this would fail on 64 bit OS. Am I out to lunch? Am I missing some flag when starting the image? Thanks again... On Sat, Mar 25, 2017 at 3:03 AM Maksym Kharchenko < ***@***.***> wrote: Stephane, I have found a possible fix for you. See bc/ling_code.erl lines 90-91. It converts reg 1023 (non-existent) to reg 255 (rarely used). It is a hack in the same vein as reg 1023 is a hack. You can add another case to convert reg 1022 to reg 254. A few comments on how LING and BEAM differ: 1. Both LING and BEAM use the same high-level instruction set you can see when you disassemble BEAM files. However, it is not the instruction set VMs execute. They execute highly-optimized low-level instructions and these are different between LING and BEAM. The low-level instruction set for LING is bc/iops.tab. 2. BEAM translates from high-level to low-level instructions upon module load. For this it uses a sophisticated engine similar to a Prolog interpreter. LING does the translation statically upon compilation of the module. .ling files contain low-level instructions. The goal of the approach is to make LING start faster. 3. Both BEAM and LING use specialized 'variants' for low-level instructions. For instance, there may be instruction variant to add a register to reg0 and a more general variant to add two arbitrary registers. The difference is that BEAM enumerates all instruction variants statically. LING 'discovers' optimal instruction variants by collecting statistics on a body of Erlang sources (stdlib). More variants allow the C compiler produces a faster code, but at the same time increase the code size of the interpreter. You can see discovered instruction variants in bc/ling_iopvars.erl (after the build). 4. The main source of LING interpreter is core/ling_main.c. The file is generated to accommodate for all instruction variants discovered earlier. Regards, M On Sat, Mar 25, 2017 at 2:33 AM, Stephane Bourque < ***@***.***> wrote: > Thanks for looking into this Maxim. > > I am still interested. If you could point me in the right direction, I > would love to investigate and see if I can address this issue. > > I assume I need to look for changes in Beam in R19 to previous revs. Are > there some additional docs for Ling and how it differs from Beam? > > I appreciate any info.. > On Tue, Mar 21, 2017 at 19:08 Maksym Kharchenko < ***@***.***> > wrote: > > > This is likely a change to the Erlang compiler introduced in R19. > > > > The compiler used to emit references to a 'temporary' registers, such as > > r1024 despite the fact that there are only 256 registers. Maybe, now > > compiler emit references to more of such short-lived out-of-bound > > registers. > > > > Anyways, the investigation and correction will take considerable time I > do > > not have now. > > > > Regards, > > M > > > > > > On Mon, Mar 20, 2017 at 6:16 AM, Stephane Bourque < > > ***@***.***> > > wrote: > > > > > @maximk <https://github.com/maximk> Thanks for helping... > > > > > > Here is the first significant warning > > > > > > > > > > > > > > > > > > > > > > > > *core/ling_main.c: In function ‘proc_main’: core/ling_main.c:5678:3: > > > warning: array subscript is above array bounds [-Warray-bounds] > rs[1022] > > = > > > *(term_t *)expand_ptr(tmp_arg1); ^ core/ling_main.c:5976:7: warning: > > array > > > subscript is above array bounds [-Warray-bounds] if (rs[1022] != > > > (term_t)ip[2]) ^* > > > > > > Now changing NUM_REGS to 1024 fixes the warning, but I see some > > > significance to 1022. > > > > > > Here is the error when running railing image for cowboy's hello_world > > > example. > > > > > > _Compile: > > > > > > > > > > > > > > > > > > > > > > > > *rel/hello_world_example/lib/asn1-4.0.4/ebin/asn1ct_check.beam > escript: > > > exception error: no function clause matching > > > ling_lib:enc({reg_as_term,1022}) (bc/ling_lib.erl, line 233) in > function > > > ling_lib:'-encode/1-lc$^0/1-0-'/1 (bc/ling_lib.erl, line 231) in call > > from > > > ling_lib:'-encode/1-lc$^0/1-0-'/1 (bc/ling_lib.erl, line 231) in call > > from > > > ling_lib:encode/1 (bc/ling_lib.erl, line 231) in call from > > > ling_lib:code_chunk/1 (bc/ling_lib.erl, line 174) in call from > > > ling_lib:specs_to_binary/1 (bc/ling_lib.erl, line 125) in call from > > > railing:compile/2 (railing/railing.erl, line 399) in call from > > > railing:'-main/1-lc$^9/1-8-'/2 (railing/railing.erl, line 198)* > > > > > > This 1022 pops again. Happens wetter the NUM_REGS is set to 1024 too. > > > > > > I compiled LING with the latest build-essential, using Erlang V19.2 > > > > > > I added a new BIF for erlang:timestamp() (I just duplicated what was > > there > > > for erlang:now() ). > > > > > > Let me know if you need anything else. > > > > > > Thanks > > > > > > — > > > You are receiving this because you were mentioned. > > > Reply to this email directly, view it on GitHub > > > <#141 (comment) >, > > or mute > > > the thread > > > < > > https://github.com/notifications/unsubscribe- > auth/AAEFTA0aJNG1PAhQG2ncGe_WjwrW9U7pks5rnf2HgaJpZM4ImGyY > > > > > > . > > > > > > > — > > You are receiving this because you commented. > > Reply to this email directly, view it on GitHub > > <#141 (comment)>, > or mute > > the thread > > <https://github.com/notifications/unsubscribe-auth/ > ABxfxBljYA4K70vAJorykcvY14vgcm58ks5rn6-fgaJpZM4ImGyY> > > . > > > > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#141 (comment)>, or mute > the thread > < https://github.com/notifications/unsubscribe-auth/ AAEFTOY5ys2v8B21MEzEQiQQk9M0ho_qks5rpGDxgaJpZM4ImGyY > > . > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#141 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABxfxBjZo0MxWXvzmLBy_ HP5G_KHFH2Lks5rpOZVgaJpZM4ImGyY> . — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#141 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEFTMgBBHzFjFl90WAT_QxZgoLL5lkyks5rpa6GgaJpZM4ImGyY> .

[howard0su]

I made some progress towards enabling erlang 19.0. Now I crashed at: but at least otp is starting.

TRACEEX: caught [<0.10.0>] error:badarg stack [{maps,merge,[#cp,#err(0x1027e94e)],[]},{supervisor,check_flags,1,[{file,"supervisor.erl"},{line,1254}]},{supervisor,set_flags,2,[{file,"supervisor.erl
"},{line,1244}]},{supervisor,init,1,[{file,"supervisor.erl"},{line,296}]},{gen_server,init_it,6,[{file,"gen_server.erl"},{line,328}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,247}]}
]